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.

Reply via email to