Thanks Alan. I think this is exactly the issue I was hitting. Is it currently not possible to ensure modules have not been tampered with? I don’t think my application will ever be properly modularized anyway, so I will simply make sure those jars are only on the class path. But I’m a little surprised that a security issue like this would linger for so long.
I guess with the removal of applet and web start support this issue wasn’t deemed as serious as it otherwise would be. Regards, Scott > On Oct 7, 2018, at 3:49 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 06/10/2018 06:21, Scott Palmer wrote: >> As is too often the case I discovered the difference while trying to isolate >> a test case. With Java 10 I had extra JVM args to deal with module path and >> that appeared to cause the problem. > There is very limited support for signing of modules and signed modular JARs. > JDK-8194930 [1] tracks the issue of the protection domain not including the > signing info but there are other issues, mostly at link-time where jlink will > report an error if you attempt to creating a run-time image containing a > signed module. > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8194930
