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
