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.


Reply via email to