Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179025/webrev.00/index.html
These tests failed due to IAE when loading types from the deployment
modules which are expected to be defined when running with javaws
or plugin. This revises the tests to exclude these modules to
remove the
Changeset: b38f70bbe88d
Author:alanb
Date: 2017-04-21 20:12 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b38f70bbe88d
SecurityManager should not record packages of modules defined to app loader
! src/java.base/share/classes/java/lang/SecurityManager.java
Changeset: 8d25210fce7b
Author:alanb
Date: 2017-04-21 17:57 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8d25210fce7b
Load SecurityManager's non-exported packages when needed rather than eagerly
! src/java.base/share/classes/java/lang/Module.java
!
On 21/04/17 11:57, Alan Bateman wrote:
> The check in checkUnprivilegedlookupClass isn't new, I think it's a
> defense-in-depth check that goes back to JDK 7 to catch usages of full
> power lookups in fully privileged code. There was recent discussion on
> core-libs-dev about this, prompted by
There has been some discussion about whether we want to update Graal in the JDK
at this late stage. The main (only?) risk is a regression in the AOT tool.
If we don't update Graal from upstream, then the qualified exports from JVMCI
to jdk.internal.vm.compiler cannot be removed in JDK 9. Note
On 21/04/2017 11:04, Andrew Dinn wrote:
Being a good OpenJDK citizen I have attempted to make my agent use
lookups in jdk9 in place of using reflection. This is mostly working
fine. However, I have run across a rather arbitrary limitation (not just
my conclusion -- the jdk source code
Being a good OpenJDK citizen I have attempted to make my agent use
lookups in jdk9 in place of using reflection. This is mostly working
fine. However, I have run across a rather arbitrary limitation (not just
my conclusion -- the jdk source code acknowledges it as such) and am
wondering whether
