A curiosity: is jdk.pack a morally split package?
Simon Spero
sesuncedu at gmail.com
Sun Jun 18 17:02:11 UTC 2017
[I haven't noticed any similar cases. I wouldn't have noticed this if I
hadn't been looking for the source code. I know why this works, and how
much of a pain it would be to try and stop it working]
According to the module-info, jdk.pack is not concerned with packages
module jdk.pack {
<http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c31ac0b8a60e/src/jdk.pack/share/classes/module-info.java#l41>
}
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c31ac0b8a60e/src/jdk.pack/share/classes/module-info.java
However, its share/native/libunpack directory contains a single source
file, jni.cpp, which implements the native methods for a Java class:
#include <com_sun_java_util_jar_pack_NativeUnpack.h>
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c31ac0b8a60e/src/jdk.pack/share/native/libunpack/jni.cpp
The jni code relies on other native libraries in jdk.pack; these libraries
are also used by some native command line binaries.
The Java class, com.sun.java.util.jar.pack.NativeUnpack is in the module
jdk.base, in a package containing other classes. This class attempts to
load the native library "unpack".
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c31ac0b8a60e/src/java.base/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
If this class cannot be instantiated (or if a debug property is set
requesting that the native code not be used, unpacking is done using
fallback code.
Oddly, the public API defined in java.util.jar.Pack200 specifies a Provider
interface (java.util.jar.Pack200.Unpacker).
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c31ac0b8a60e/src/java.base/share/classes/java/util/jar/Pack200.java
However, there is only a single implementation of this interface,
com.sun.util.jar.pack.UnpackerImpl, which does little except for attempting
to instantiate NativeUnpack, and providing a thin wrapper around the
fallback code if the unpacking fails.
However, there is only a single implementation of this interface.
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c31ac0b8a60e/src/java.base/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java
Some points of interest:
1. Conceptually, bits of the com.sun package are split between two modules.
2. jdk.base depends on jdk.pack for the native library. (At runtime).
3. jdk.pack depends on jdk.base for the header. (At compile time).
4. The dependency could be broken via the ServiceLoader mechanism, except
the code mostly hasn't been touched since before jdk 6.
5. The man pages for pack200 and unpack200 are under jdk.base.
An interesting thought experiment would be to consider a hypothetical
system which used an opencl like mechanism where implementations of native
methods could be carried in source code or IR. Another wrinkle would be if
AOT compiled code were carried in a similar fashion.
Simon
More information about the jdk9-dev
mailing list