Multi release jars on boot classpath

[Alan Bateman]

On 02/06/2016 12:36, Michael Rasmussen wrote:

> I can only say that I'm disappointed that the null-classloader will be
> excluded from this JEP, as I do consider it one of the standard class
> loaders in the JRE, which is defined as a goal for the JEP.
>
> As for being an uncommon way to deploy libraries, I do think it's
> common for java agents to either add themselves via entry in the
> manifest, or have their premain class add the jar via Instrumentation
> API, as this is the only way if you want to instrument classes loaded
> with the null-classloader to call into your code.
>
> but guess I'll have to litter my agent code with if (isJDK9()) check
> to conditionally load classes for supporting Module etc.
>
JEP 238 needs several updates and I think could be clearer that 
multi-release JARs can be deployed on the class path or application 
module path. Additionally, multi-release JARs can be supported by custom 
class loaders, esp those based on URLClassLoader or that use the JarFile 
API in their implementation.

We do of course understand that agents need to put supporting classes on 
the boot class path when instrumenting the code in core modules but this 
is a somewhat specialized need. Also with the ongoing effort to move 
modules away from the boot loader then it starts to reduce the set of 
possible libraries that can be deployed with -Xbootclasspath/a. So I 
think it is right to keep JEP 238 focused and get it right for the 
common scenarios first.

-Alan.