Problem with multi-release jars, agents and the bootstrap class path
Alan.Bateman at oracle.com
Fri Oct 14 08:24:35 UTC 2016
On 13/10/2016 21:43, Andrew Dinn wrote:
> I am aware that the code I add to the bootstrap can only rely on a core
> subset of the JDK runtime classes being available. That ought not to be
> an issue -- I have deliberately kept the agent's footprint as small as
> possible because every time Byteman uses an API it makes it trickier to
> instrument the API class. I'd be interested to know what you are hoping
> to exclude though, just in case. Am I ok with print stream? file
> streams? localhost server sockets? Just checking :-)
The granularity is module. It would be great if we could somehow get to
the point where the only module defined to the boot loader is java.base
but that is a long way off (java.desktop is the biggie that would need
to move before its dependences can move). If it were just java.base then
the "core" APIs would be visible, this includes file and networking.
> Yes, by hoisting I mean precisely that. The minor wrinkle that the class
> which adds the agent jar to the bootstrap path actually gets loaded from
> that same jar (but via the system classpath) is what led me to use the
> term 'hoist'. There is probably a joke in here somewhere about 'my own
> petard' but I'll demur.
LOL but yes, major hazards here as presumably you have types of the same
name defined to both the system and boot loaders.
> It's a shame multi-release won't work for all agents but never mind.
I see Paul has updated the text in JEP 238 to make this clear.
More information about the core-libs-dev