Ok, thanks. Rémi
On April 8, 2017 4:49:13 PM GMT+02:00, Mandy Chung <mandy.ch...@oracle.com> wrote: >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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
