Problem with multi-release jars, agents and the bootstrap class path

[Alan Bateman]

On 13/10/2016 17:40, Andrew Dinn wrote:

> :
>
>
> A Few Questions:
>
> Am I right that this is a deliberate choice of bootstrap loader
> behaviour? Or is there perhaps some other bug here?
>
> If this is a deliberate choice is there any possibility of reviewing it?
>
> Would it be particularly difficult to modify the boot loader to
> recognise jars in multi-release format?
>
>
What you see is deliberate. It wouldn't be impossible for the boot 
loader to support MR JARs but it hardly seems worth the complexity. One 
reason is that it's not a common way to deploy a general purpose 
library. Even if it were then it would be problematic going forward as 
we reduce the number of modules defined to the boot loader (you can't 
instrument code in core modules to call into a SQL library for example 
because java.sql types are not visible to code in the boot loader). The 
other thing is that the boot class path as we used to know it is mostly 
gone, it only really exists when using -Xbootclasspath/a or when JVM TI 
or java.lang.instrument do the equivalent.

For the "hoist"-ing scenario then I assume you mean 
Instrumentation::appendToBootstrapClassLoaderSearch to add supporting 
classes to the boot class path so that they are visible to instrumented 
code. Can you use the same method to append a JAR file containing 
53.0/9+ classes before you append the other JAR. That should be 
equivalent to what a MR JAR would give you, albeit without the 
convenience of everything in one artifact.

-Alan