Pick a path, any path

As heard at JavaOne this year, classpath is dead, being killed by the modularity features in JDK 7, JSR 294 and Project Jigsaw.

Today the full logical classpath available to an application or used in javac is actually a twisty little maze of concatenated sub-paths, starting with the bootclasspath, followed by the extension directories, and finally the classpath setting itself. The endorsed standards override mechanism is used to selectively update various components logically included on the bootclasspath as part of the JDK, either components for standards that evolve outside of the JCP, like Corba, or standalone JSRs also shipped with the JDK, like JAX-WS. The extension mechanism can be used to support technologies not shipped with the JDK, such as an independent JSR or even a site-wide library.

The table below shows the different command line options to java and javac that can be used to configure the sub-paths. These options have evolved over time. The bootclasspath and extension directories were added in JDK 1.2, the ability to prepend to the bootclasspath was added in JDK 1.3, endorsed standards were added in JDK 1.4, JDK 5 harmonized the path options on the java and javac command lines, and JDK 6 allowed classpath wildcards, but only for the strict classpath component and not for bootclasspath or the Class-Path Jar manifest attribute. Check the documentation for the JDK release in question for matching configuration information.

There is certainly plenty of opportunity for modularity in JDK 7 to simplify the configuration options needed to resolve dependencies!

Path Setting in java and javac
bootclasspath/p: Endorsed standards bootclasspath[/a:] Extension Directories classpath
java options -Xbootclasspath/p: -Djava.endorsed.dirs= -Xbootclasspath:
-Djava.ext.dirs= -cp
javac options -Xbootclasspath/p: -Djava.endorsed.dirs= -bootclasspath


I never really understood the endorsed standards mechanism. On what level does it operate? How does the VM know which classes/packages are obsoleted when you add something to your endorsed dirs? How can it know whether or not a package/class is part of the endorsed version or not? Or does it just work additive to the bootclasspath? But then what about classes that are not in your endorsed dir, but that are still on the bootclasspath? Wouldn't you end up with an inconsistent mismatch of classes/packages for a component?

Posted by Mark Wielaard on July 21, 2009 at 07:28 PM PDT #

Mark, endorsed standards is a boot classpath prepend mechanism. The picture above seems to imply that it comes after -Xbootclasspath/p, but I had thought it was prepended before everything. As for class mismatches, I think the intention is to wholly replace a set of classes or packages.

Posted by bkail on July 22, 2009 at 01:52 AM PDT #

Yes, prepending the individual classes in the endorsed dirs to the normal vm bootstrap classes seems like a simple implementation strategy.

But I don't get what guarantee there is for wholly replacing one such "module", which can consists of multiple classes and packages. And where the replacement can exist of a different sub and super set of those classes and packages.

What is the mechanism that provides the "logically" part of the "selectively update various components logically included on the bootclasspath" in the override mechanism? This doesn't seem to be defined anywhere I can find.

Posted by Mark on July 22, 2009 at 03:40 AM PDT #

@Mark and @bkail,

Yes the endorsed standards mechanism effectively lets you prepend the contents of the chosen directories to the bootclasspath. Therefore, the definition of the classes defined there will override any corresponding definitions otherwise on the bootclasspath, such as in rt.jar.

The intention is that a whole component is upgraded by the endorsed standard. The rules only allow selected technologies to be so upgraded; whether or no the mechanism enforces those rules is another matter...

Being able to reason about and bundle components as modules should improve their encapsulation.

One limitation of the endorsed standards mechanism is that there is not a corresponding way to allow such a component to be replaced in a ClassLoader while following the delegation model.

Posted by Joseph Darcy on July 22, 2009 at 03:52 AM PDT #


There are no such guarantees I'm aware of in the implementation against malicious or ill-formed replacement jars being populated into the endorsed standards location. By default, the endorsed directories list points into the JRE/JDK install tree so it is assumed to only be writable by trusted parties.

Having a explicit modules concept in the platform will help address such component integrity concerns.

Posted by Joe Darcy on July 22, 2009 at 07:32 AM PDT #

Thanks for the explanations Joe. Is there a definition of "ill-formed"?

As you say having an explicit modules concept will help with component integrity concerns. But only if it makes it possible to express the current rules. And when such "rules" are clear/well defined.

Posted by Mark Wielaard on July 23, 2009 at 04:27 AM PDT #

I hope that Jigsaw includes some mechanism to integrate Java packages to the package management feature of OSes like Linux and Solaris. So if an app XYZ could declare a dependency on hibernate-core-3.3+, I just say "apt-get install XYZ" and it also downloads and installs Hibernate if no satisfying version is already installed. And so on for other package management operations, including automatic updates. Right now, Linux distros have to repackage supported Java apps and libraries, and this often results in people using old stuff just because the maintainer of such packages is slow. A smart Jigsaw implementation could smooth this process a lot, and make Java much more palatable for users of these systems. Java programs like Maven that perform their own package & configuration management, complete with a local repository of installed libs, could also evolve to just use Jigsaw's system, eliminating another aggravation for developers.

Posted by Osvaldo Pinali Doederlein on July 23, 2009 at 05:34 AM PDT #


Yes, Jigsaw does plan to have that depth of native package integration. Mark Reinhold demoed some of this at JavaOne this year; you can see the video under "Chapter 2" of

Posted by Joe Darcy on July 23, 2009 at 04:13 PM PDT #


In this case, I was using "ill-formed" to mean in any way not well-formed, such as the replacement jar not redefining certain classes, etc.

One of the problems today is that the "rules" do not have a consistent enforcement mechanism in the platform. A modules facility will provide that enforcement; e.g. classes used internally to implement a module would not be usable outside of the module.

Posted by Joe Darcy on July 27, 2009 at 02:06 PM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016

No bookmarks in folder