Use of JDK interanl ASM vs external

[Alan Bateman]

On 18/02/2015 11:21, Remi Forax wrote:
>
> Currently, the version of ASM shipped with the JDK is a customized 
> version compiled directly from the trunk and lightly patched to bubble 
> up some internal methods that are not part of the public API.
>
> In jdk8 world, it's an internal API and you should not use it.
>
> In jdk9 world, the classes are integrated into jdk.base module (the 
> one that contains packages like java.lang) and the ASM packages are 
> only re-exported [1] for nashorn and jfr modules thus not visible by 
> the code of an application.
>
> Being a public API means to create an ASM module (or several) and make 
> jdk.base depends on this module
> without re-exporting the ASM packages.
> So the JDK and an application will be able to share the same ASM module.
>
> The issue here is that the JDK module that depends on ASM is jdk.base 
> the root of the module graph,
> so the root of the module graph is not the root anymore :(
A few other points to add to Rémi's reply.

The copy of ASM that is in java.base is in jdk.asm.internal.** packages 
so it shouldn't cause any conflicts. So while the types in these 
internal packages are visible, then the proposal is that they not be 
accessible (pretend for now that they are not public, you can "see" the 
classes but you can't access).

Having java.base depend on a jdk.asm module is also a problem because it 
leads to a circular dependency. Having java.base export the ASM API is a 
problem too, it goes against the design principles in JEP 200 where 
standard modules should only export standard APIs.

-Alan.