No change in that regards. The updated test [1] in the webrev shows it patches java.base/jdk.internal.modules.SystemModules
Before this fix, you can do —patch-module jdk.internal.vm.compiler=.jar —upgrade-module-path graal.jar. The reason is that —patch-module disables the hash checking that makes non-upgradeable module upgradeable. After this fix, it fails if you attempt upgrade a patched non-upgradeable module. [1] http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01/test/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java.frames.html > On Apr 8, 2017, at 7:22 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > > Hi Mandy, > how can I test a change in java.lang after that patch ? > > Rémi > > > On April 8, 2017 7:50:50 AM GMT+02:00, Mandy Chung <mandy.ch...@oracle.com> > wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01 > <http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01>/ > > This fixes -—patch-module to do hash checking on the module being patched > so that it will ensure that a non-upgradeable module remains not upgradeable. > > As Graal has been using —-patch-module option to disable the hash checking > to load a different version of jdk.internal.vm.compiler, it needs a > mechanism to load Graal, as tracked by JDK-8177845. > > Mandy > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.