Need help testing the EA builds

[Alex Buckley]

On 3/2/2016 8:29 AM, Stephen Felts wrote:
> Yes, you are correct.  The rt.jar change and the classloading changes have caused many of these tools problems.  I should have tried to separate the Jake from non-Jake problems.
> I've also been entering bugs where possible.  I entered them for gradle, jython, eclipselink, and findbugs for tools outside Oracle.
>
> Using upgrade, module, and patch files is clearly Jake as are the need to use exports.
> Jmockit and Simplestub are I think partly related to Jake but it's hard to tell until we figure out the full problem.
> Passing information to the Gradle daemon is Jake related (separate from the junit problem).

Let's clarify that "Jake problems" arise for two very different reasons:

1. A limitation (usually deliberate, sometimes accidental) in a 
mechanism of the module system.

2. A policy decision by the JDK team during JDK modularization, 
implemented via a mechanism of the module system.

Needing to use -XaddExports for JDK modules is due to (2). JEP 260 sets 
forth the policy of limiting access to non-standard, unstable, and 
unsupported APIs. The policy could have been set forth at any time in 
the last twenty years, and been implemented by (say) renaming internal 
packages in every major JDK release. It "just so happens" that the 
policy is now implemented via a mechanism of the module system (i.e. not 
exporting certain packages).

Needing to use -upgrademodulepath and -Xpatch for JDK modules is due to 
(1). The module system is philosophically opposed to split packages, so 
attempting to augment packages in JDK modules by placing classes on the 
classpath doesn't work by design. We are aware that certain packages in 
the JDK (e.g. javax.annotation) are frequently augmented on the JDK 8 
classpath by third party JARs (e.g. jsr305.jar), and that this implies 
widespread use of -Xpatch on JDK 9 ... this should be addressed by a 
policy of JDK modularization rather than a change to the module system 
proper.

Alex