A curiosity: is jdk.pack a morally split package?

[Simon Spero]

[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