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

Andrew Dinn adinn at
Thu Oct 13 16:40:34 UTC 2016


Although this post relates to handling of multi-release jars I'm
cross-posting to jigsaw-dev as well as core-libs-dev. That's because the
problem arises only because my JVMTI Java agent now needs to operate in
dual mode to cope with Jigsaw when deployed on JDK9+ and to avoid
reference to Jigsaw when deployed on JDK8-, hence the desire to use the
multi-release format. Apologies if the cross-post is redundant.

The Problem:

I have re-packaged my Byteman JVMTI Java agent using a multi-release jar
format so that it can operate as is on JDK8- (compiled as target 6 and
no reference to Jigsaw code) while providing revised functionality on
JDK9 that accounts for the presence of modules. This works fine if I
deploy the agent on the system classpath.

However, for some modes of operation my agent Main class hoists the
agent jar into the bootstrap classpath. This is needed so that I can
inject references to agent classes into JDK bootstrap code like Thread
etc. The problem is that bootstrap loader does not appear to recognise
that the jar is in multi-release format.

I can understand that this may seem to be an appropriate behaviour under
the assumption that code in the bootstrap ought to be the JDK runtime
code and therefore ought to be compiled at the current JDK/JVM version.
However, that assumption doesn't really hold when the code in question
is an agent which may well need to operate on old and new JDK versions.

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?

Thanks in advance!


Andrew Dinn
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

More information about the core-libs-dev mailing list