giltene / jHiccup

jHiccup is a non-intrusive instrumentation tool that logs and records platform "hiccups" - including the JVM stalls that often happen when Java applications are executed and/or any OS or hardware platform noise that may cause the running application to not be continuously runnable.
Other
677 stars 92 forks source link

Added tools.jar explicitly to dependencies #6

Closed bonifaido closed 10 years ago

bonifaido commented 10 years ago

On Mac OS X 10.9 with java 1.7.0_45 I couldn't get it compiled without adding the tools.jar as an explicit dependency.

giltene commented 10 years ago

I think thus has to do with your IDE (or environment) using a JRE instead of a JDK for running maven. I don't like the idea of adding a dependency on a specific tools.jar version or a specific directory structure that finds it on some systems, as that won't be portable; neither to other OSs or even to MacOS that doesn't have a 1.6.0 Java JDK installed somewhere.

bonifaido commented 10 years ago

I'm running maven with JDK 7. This official maven page helped me to resolve the issue. Actually the version number in the dependency section is very relaxed in this case because it directly points to the exact jar file instead of using the resolution mechanism.

After reading this Java 7 article I found the following:

The tools classes in tools.jar are only used to run javac and javadoc. The tools classes are not used to resolve source code references unless tools.jar is in the user class path.

May I ask you which JDK are you using, Oracle or OpenJDK? Maybe this makes a difference.

giltene commented 10 years ago

The page you refer to does show how to add a tools.jar dependency, but while that may work to resolving a private system issue, I doubt that it's portable (and wouldn't want to have to test all the various platforms). The expectation is that you use a JDK (and not a JRE) to build things, and I don't think tools. jar will be missing if you have a JDK as yu JAVA_HOME.

On my Mac, I use Java 6 and Java 7 JDKs, downloaded from the Oraclehttp://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

I use Java 6 to build jHiccup to make sure it doesn't rely on Java 7 things, but the same should work with Java 7 JDKs, obviously.

% env | grep JAVA_HOME JAVA_HOME=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

% java -version java version "1.6.0_65" Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

Maven works from the command line with this. And from IntelliJ.

bonifaido commented 10 years ago

You're right, adding something like this to the pom doesn't sound like a good idea. However I have tried to build with JDK 6 and it works as it should:

export JAVA_HOME=/Library/Java/JavaVirtualMachines/1.6.0_51-b11-457.jdk/Contents/Home
mvn clean package

When I change to JDK 7

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home
mvn clean package

somehow tools.jar disappears from the classpath and I get the compile errors.

giltene commented 10 years ago

Ok. I see the same problem with 1.7.0_45 on my Mac. As ugly as it is, I guess maven won't be pacified without the dependency (no good way to add tools.jar to the compilation class path without it). To make sure this effects only for the compilation, and not in the packaging, I've merged the pull request, and added the following:

  1. An exclude to the dependency plugin: tools
  2. Changed version to an intentionally non-sensical one (99.9).

[Note: The version number is irrelevant for how a system path dependency is located, and appears to only affect how the result is copied into the target directory. Since We're excluding the tools.jar from actually being copied to the target directory, the version number is meaningless (but still required syntactically). To make sure people don't confuse it with something else, I'm numbering it with 99.9 instead of 1.6]