Project Jigsaw: Supporting modules with platform specific classes or native code

This page outlines our approach to supporting modules with platform specific classes and/or native code. The term "platform" here is intended to cover operating system and architecture, for example windows-x64 or solaris-sparc. It may also indicate the EABI or processor features, for example linux-armv5-sflt.


Our proposal is to allow modules be platform specific. That is, a module may contain classes, native libraries, and/or other files/resources that are specific to one platform. The majority of modules are likely to be platform independent (noarch). Many of the modules that make up the JDK will be platform specific.

The approach does not preclude cases where a developer decides to split a module into its shared and platform specific parts (see Alternatives). Where the platform specific part is required and is significant, then it may be simpler to combine into one platform specific module.


The main alternative that we examined was so called "Fat/Universal" modules. In this approach a module may contain classes and/or native libraries for more than one platform. Issues with this approach are:

OSGi appears to have support for universal modules by means of a Bundle-NativeCode header. It requires further investigation to know if their solution is limited to native libraries or whether it supports platform specific classes and other files too.

We also examined the approach where a module is split into "shared" and platform specific modules. Module "foo" may require (or optionally require) "foo-platform-specific" for example. This approch is not precluded by the solution proposed.

One issue with this approach is that it wouldn't allow the platform specific module to be solely a native library. Instead it would minimally require a shim that loads the native library and invokes the native methods (the need for the shim stems arises because module A will not load native libraries located in module B).

JDK modules in the module library

The current module image places the native libraries for the JDK modules in the image's lib directory. We intend to change this so that the JDK modules are organized in the same way as application modules. For example, the native libraries for the base/boot module will be located in jdk.boot/8.0/lib.

This layout assumes that we are not required to have both 32-bit and 64-bit binaries in the same JDK image (as is currently done on Solaris with the legacy image).

The bin directory will remain so that java and other commands can be launched from $JAVA_HOME/bin.

Moving to the layout requires addressing several dependency issues:

Items that require further investigation