Multi release jars on boot classpath

[Alan Bateman]

On 02/06/2016 13:38, Andrew Dinn wrote:

> :
> Can you explain what this means in any more precise detail?
>
> Those of us who are trying to maintain agents are currently having to
> work on shifting ground where it seems the only guidance we have as to
> what will and won't work is the current code. This is the second
> occasion where a throwaway comment has revealed to me that plans are
> afoot to change functionality that my agent (and doubtless others too)
> relies on. If there are plans afoot of this nature then we need to know
> about them well before it happens. OpenJDK project members -- especially
> those who have implemented agents -- need to discuss whether the
> resulting breakage of existing functionality is acceptable. That sort of
> decision cannot be arrived at as a fait accompli simply by virtue of the
> fact that your envisaged Jigsaw design will produce it as a side effect.
There has been ongoing effort to improve the security of the platform 
for a long time. The ongoing effort that we have been calling 
"de-privileging" involves moving non-core components out of the boot 
loader and granting these components reduced permissions where possible. 
This effort is not core to what we are doing here but having the JDK 
structured as modules, and making it easy to map modules to class 
loaders, has allowed this effort to make progress. I think most of the 
discussions on specific modules has been on the core-libs-dev or 
security-dev lists. There is a table in JEP 261 of the modules that have 
moved and this needs to updated because we have moved several other 
standard and JDK modules in recent months.

So my point is that the set of types visible via the boot loader has 
been reducing steadily. This is a good thing for security but it comes 
with compatibility concerns. This is very much a change for a major 
release of course. One concern is custom class loaders that delegate 
directly to the boot loader. Eclipse is one example - there was a brief 
discussion about that on jdk9-dev some time ago.  The other issue is 
agents that have supporting classes on the boot class path. This code 
won't be able to statically reference types in modules that have moved 
to the platform class loader (platform class loader = what used to be 
known as the "extension class loader"). Related is where an agent 
instruments code in modules defined to the boot loader in a way that 
would result in references to types in the platform class loader (the 
boot loader does not delegate). I think we will need feedback and help 
to assess the impact. It may be that agents working at this level aren't 
depending on types in non-core modules. However, I think this thread is 
a reminder that there will need to improvement documentation on this 
implementation issue. So far, the document is make/common/Modules.gmk as 
that is where the mapping lives.

-Alan