The next screen snapshot demonstrates running the newly compiled Main.class class and having the dependency PersonIF.class picked up from archive/PersonIF.jar without it being specified in the value passed to the Java application launcher's java -cp flag. This demonstrates that the Oracle-provided Java compiler considers the classpath content specified in the Class-Path header of the MANIFEST.MF of any JAR on specified on the classpath. It's interesting to see that the search path for class files (as well as the search path for source files) includes archive/PersonIF.jar even though I did not specify this JAR (or even its directory) in the value of -cp. The "search path for class files" was the significant one in this case because I had moved the PersonIF.java and Person.java source files to a completely unrelated directory not in those specified search paths. The output of javac -verbose provides the "search path for source files" and the "search path for class files". Why did this compile when I had not explicitly specified PersonIF.class (or a JAR containing it) as the value of classpath provided via the -cp flag? The answer can be seen by running javac with the -verbose flag. I formerly would have expected compilation to fail when javac would be unable to find PersonIF.jar in a separate subdirectory. I will now attempt to compile the Main.class from Main.java with only the current directory on the classpath. The Person.class file will exist in its own Person.jar JAR file and that JAR file includes a MANIFEST.MF file with a Class-Path header referencing PersonIF.jar in the relative subdirectory. I will intentionally place the PersonIF.class file in its own JAR called PersonIF.jar and will store that JAR in a (different) subdirectory.
Path to java jar file code#
Public static void main(final String arguments)Īs can be seen from the code listings above, class Main depends upon (uses) class Person and class Person depends upon (implements) PersonIF. The code listings are shown next for these. To demonstrate this, I'm going to use a simple interface ( PersonIF), a simple class ( Person) that implements that interface, and a simple class Main that uses the class that implements the interface.
It turns out that the Class-Path entry in a JAR's manifest affects the Java compiler ( javac) just as it impacts the Java application launcher ( java). The section " Adding Classes to the JAR File's Classpath" of the Deployment Trail of The Java Tutorials states, "You specify classes to include in the Class-Path header field in the manifest file of an applet or application." This same section also states, "By using the Class-Path header in the manifest, you can avoid having to specify a long -classpath flag when invoking Java to run the your application." These two sentences essentially summarize how I've always thought of the Class-Path header in a manifest file: as the classpath for the containing JAR being executed via the Java application launcher ( java executable). This post demonstrates this new-to-me nuance. A colleague recently ran into an issue that surprised me because it proved that a JAR file's Manifest's Class-Path entry also influences the compile-time classpath when the containing JAR is included on the classpath while running javac.
I've known almost since I started learning about Java that the Class-Path header field in a Manifest file specifies the relative runtime classpath for executable JARs (JARs with application starting point specified by another manifest header called Main-Class).
0 kommentar(er)
