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
