Skip to content
Advertisement

Split Packages: Java Modules vs Sealed Jars

Both Sealed Packages/Jars and the Java Module System disallow spliting packages across several jars. Does that mean that all packages contained within a Module are implicitly sealed? If not what does explicitly sealing the jar change?

Advertisement

Answer

Yes, packages within modules are always implicitly sealed. This is specified in the documentation of the Package class:

A Package automatically defined for classes in a named module has the following properties:

  • The name of the package is derived from the binary names of the classes. Since classes in a named module must be in a named package, the derived name is never empty.
  • The package is sealed with the module location as the code source, if known.
  • The specification and implementation titles, versions, and vendors are unspecified.
  • Any annotations on the package are read from package-info.class as specified above.

I also made a quick test to verify that isSealed() on a module’s package did indeed return true. However, it must be noted that the relationship between (named) modules and packages is of a fundamental nature and hence, independent of the fact that isSealed() returns true. The latter is just the natural way for the old API to interact with this new feature.

A sealed package of an unnamed module only affects the runtime package of the particular class loader, as each class loader can have a package of the same name, which is considered a different runtime package.

In contrast, each package of a named module must unambiguously belong to a single module within the entire module layer and a module layer can span multiple class loaders, e.g. the boot layer spans the bootstrap loader, the platform loader, and the application loader.

This affects the class loading process. The old way of loading, which is still used for the unnamed module, features class loader delegation where each loader queries its parent loader first. When the parent loader failed, the class path entries are queried linearly for the class until a class is found.

When a module layer is initialized, all package names and their owning modules are recorded, so when an attempt to load a class is made, the package name can be derived from the qualified name and mapped to a module even before the class is loaded and therefore, only the module’s known source needs to be queried.

User contributions licensed under: CC BY-SA
10 People found this is helpful
Advertisement