Monday, March 23, 2009

Perils of (Ab)using the java.ext.dirs Property

I frequently use the java.ext.dirs system property as a shortcut for setting the classpath for a command-line Java program, i.e.:

java -Djava.ext.dirs=lib com.scottmcmaster365.MyMainProgram

No, this isn't great for production use, but for quick-and-dirty testing, it's much more convenient than creating a launcher batch file / shell script or manually typing a ginormous claspath.

Well, this practice jumped up and bit me the other day. After the requisite amount of pain and suffering, I observed that setting java.ext.dirs does not extend but rather overrides the real optional-extension location (at least with Sun's JVM), as sort-of-alluded-to here. As a consequence in this situation, Java will, at runtime, lose track of your optional packages. In my case, this manifested itself as an inability to load the JCA crypto providers (i.e. ClassNotFoundException).

If you're not using any of the standard optional packages, setting your own extensions path doesn't seem to matter. But I guess the moral of the story is that you shouldn't count on the extension mechanism to stand in for the classpath mechanism, even in all expedient situations.

1 comment:

Zhenya said...

http://java.sun.com/j2se/1.5.0/docs/guide/extensions/spec.html states, that "...This property specifies one or more directories to search for installed optional packages, each separated by File.pathSeparatorChar."
So, you can still use it with : or ; separator, depending on the OS you use :-)