The Path to Zen

A Small Gotcha in java.lang.Package

Class java.lang.Package provides a few methods that returns certain manifest attributes such as Specification-Version or Implementation-Vendor. These attributes are loaded from the jar file in which the package is located.

The gotcha comes when you have the same java package spreaded over more than one jar file. Since there is always only one Package instance for all the classes belonging to this package (within each classloader’s scope, of course), it’s pretty much up to a classloader implementation to choose which MANIFEST.MF from all those jar files should speak for the entire package. Usually, for the obvious caching reason, the first one wins.

The worst scenario happens when you have an exploded class directory at the beginning of the classpath, in which a single class from package foo.bar (say a patch class) would cause all the classes in foo.bar, albeit well contained in a jar themselves, to lose their manifest attributes.

The “phew” part in this story is this: the Sealed attribute is an exception to the above behavior – at least in the case of the Sun JRE. An exception is always thrown properly no matter when it’s a sealed jar loaded after an unsealed jar containing the same package or the other way around.