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

[Alan Bateman]

On 18/06/2017 18:02, Simon Spero wrote:
> [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]
>
> :
>
> 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.
Yes, this area needs cleanup. As you've found, the native methods, 
implementation, and tools are in jdk.pack but the declaring class for 
the native methods is in java.base and so is ugly. As you say, it's not 
a functional issue as the pack APIs will use the pure Java 
implementation when jdk.pack is not resolved. Using services and a 
JDK-specific service type would be the way to go. This seems a fine 
cleanup to try to do in JDK 10 and core-libs-dev is the mailing list to 
bring any suggested patches.

> 5. The man pages for pack200 and unpack200 are under jdk.base.
>
Do you mean the nroff/troff files in the jdk repo? They aren't organized 
by module at this time (JEP 201 didn't propose a layout for man pages).

-Alan