Non-core components are no longer defined to the boot loader

[Alan Bateman]

(I've changed the subject line as this thread is no longer about multi 
release JARs).

On 03/06/2016 11:13, Andrew Dinn wrote:

> :
> Of course, no one is against security just as no one is against apple
> pie. Unfortunately, "de-privileging" is one of those vanilla words like
> "modernisation" that can hide more than it reveals.
There is no intention to hide anything. In general then APIs such as 
CORBA, JAX-WS, JDBC, and other non-core APIs have no business being 
defined to the boot loader with all permissions.

> :
> The visibility of said types may well appear to Jigsaw devs to have been
> reducing steadily in what is (or, if you take into account the EA
> program, /was/ until very recently) unreleased and untried code.
> However, this is still going to amount to a step change in the operation
> of the JDK runtime for anyone moving from JDK8 to JDK9. hat step change
> may not affect many applications directly but it certainly looks like it
> is going to affect the continuity of operation of the tools and
> middleware that a lot of those applications rely on. That's not simply
> an implementation and/or documentation issue; it goes to the heart of
> what functionality developers can rely on from their tools and middleware.
>
> I don't think these issues have really begun to be addressed yet. I hate
> to say this at such a late stage in the game (no one /wants/ to be a
> Cassandra) but I think it is critical that the consequences of this
> "de-privileging" are investigated and discussed properly before JDK9 is
> released. That's not just wrt an obvious special case like agent code,
> it definitely also includes the requirements of middleware code.
The "de-privileging" has been going on for a long time. The CORBA and EE 
components were moved to the extension class loader in early 2015 for 
example. All this has been happening in the JDK 9 main line where there 
are weekly early access builds and continuous "out reach" - mostly 
communication and interaction with projects to encourage continuous 
testing with the JDK 9 builds.

As regards specs then the draft APIs for Java SE 9 specify that all Java 
SE types be visible via the platform class loader. This is the first 
time that this will be specified.


>
> There is a big list of issues on the Jigsaw issues list still to be
> talked through yet the current JDK9 implementation is moving
> relentlessly towards a looming release deadline. How do the current
> release timescales marry with the need for investigation and discussion?
> How and when are the results of any such discussion going to be taken
> into account and applied to the JDK? Is the plan to release what we have
> now and then try to back-patch fixes? That sounds to me like it would be
> a very bad move for JDK9 and, indeed, Java as a whole. What's the
> alternative plan?
I think you mean the JSR 376 issues list. I'm sure Mark will be moving 
this along soon. Once there are conclusion on issues that require spec 
or implementation changes then we'll bring those changes to JDK 9.

-Alan