Re: Module name check is too restrictive
Hi Remi,
Thanks for pointing this out. We have entered bug
https://bugs.openjdk.java.net/browse/JDK-8164969 for this issue.
Harold
On 8/28/2016 3:31 PM, Remi Forax wrote:
While testing ASM,
i've found that you can not currently load a module that has a '+' in its name.
/usr/jdk/jdk-9-jigsaw/bin/java --module-path tmp --module "foo+bar"
Error occurred during initialization of VM
java.lang.module.ResolutionException: Error reading module: tmp/foo
at
java.lang.module.Resolver.findWithBeforeFinder(java.base@9-ea/Resolver.java:735)
at
java.lang.module.Resolver.resolveRequires(java.base@9-ea/Resolver.java:86)
at
java.lang.module.Configuration.resolveRequiresAndUses(java.base@9-ea/Configuration.java:370)
at
java.lang.module.ModuleDescriptor$1.resolveRequiresAndUses(java.base@9-ea/ModuleDescriptor.java:2081)
at
jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea/ModuleBootstrap.java:263)
at java.lang.System.initPhase2(java.base@9-ea/System.java:1927)
Caused by: java.lang.module.InvalidModuleDescriptorException: foo+bar: Invalid
module name: Illegal character at index 3
at
java.lang.module.ModuleInfo.invalidModuleDescriptor(java.base@9-ea/ModuleInfo.java:804)
at java.lang.module.ModuleInfo.read(java.base@9-ea/ModuleInfo.java:92)
at
java.lang.module.ModuleDescriptor.read(java.base@9-ea/ModuleDescriptor.java:1902)
at
java.lang.module.ModulePath.readExplodedModule(java.base@9-ea/ModulePath.java:591)
at
java.lang.module.ModulePath.readModule(java.base@9-ea/ModulePath.java:268)
at
java.lang.module.ModulePath.scanDirectory(java.base@9-ea/ModulePath.java:234)
at java.lang.module.ModulePath.scan(java.base@9-ea/ModulePath.java:188)
at
java.lang.module.ModulePath.scanNextEntry(java.base@9-ea/ModulePath.java:145)
at java.lang.module.ModulePath.find(java.base@9-ea/ModulePath.java:109)
at
java.lang.module.ModuleFinder$2.lambda$find$0(java.base@9-ea/ModuleFinder.java:359)
at
java.util.stream.ReferencePipeline$3$1.accept(java.base@9-ea/ReferencePipeline.java:195)
at
java.util.Spliterators$ArraySpliterator.tryAdvance(java.base@9-ea/Spliterators.java:958)
at
java.util.stream.ReferencePipeline.forEachWithCancel(java.base@9-ea/ReferencePipeline.java:127)
at
java.util.stream.AbstractPipeline.copyIntoWithCancel(java.base@9-ea/AbstractPipeline.java:502)
at
java.util.stream.AbstractPipeline.copyInto(java.base@9-ea/AbstractPipeline.java:488)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(java.base@9-ea/AbstractPipeline.java:474)
at
java.util.stream.FindOps$FindOp.evaluateSequential(java.base@9-ea/FindOps.java:152)
at
java.util.stream.AbstractPipeline.evaluate(java.base@9-ea/AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.findFirst(java.base@9-ea/ReferencePipeline.java:476)
at
java.lang.module.ModuleFinder$2.find(java.base@9-ea/ModuleFinder.java:361)
at
java.lang.module.Resolver.findWithBeforeFinder(java.base@9-ea/Resolver.java:732)
at
java.lang.module.Resolver.resolveRequires(java.base@9-ea/Resolver.java:86)
at
java.lang.module.Configuration.resolveRequiresAndUses(java.base@9-ea/Configuration.java:370)
at
java.lang.module.ModuleDescriptor$1.resolveRequiresAndUses(java.base@9-ea/ModuleDescriptor.java:2081)
at
jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea/ModuleBootstrap.java:263)
at java.lang.System.initPhase2(java.base@9-ea/System.java:1927)
According to the spec [1] section 2.1, the module name is a name in its
internal form (JVMS 4.2.1)
so it's a sequence of unicode characters (beside '.', ';', '[' and '/')
separated by '/'.
So '+' is a valid character.
The code that checks the name of a module is in
jdk.internal.module.Checks::requireModuleName and it checks that the name is a
valid Java identifier which is obviously wrong.
The module name of a module-info.java is a java identifier because it is parsed
by javac but a module name in a module-info.class is encoded a binary name to
not add restrictions to module names defined by other languages than Java.
There is also a pending spec issue [2] to make a module name a unicode sequence
of any characters and not a binary name removing the restriction around the
characters ('.', ';', '[').
For '/', it's a little different because if a module name allows '/', the
encoding of the option '--module' of the java executable becomes ambiguous.
regards,
Rémi
[1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html
[2] http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFileModuleName
Re: RFR 8159004: jlink attempts to create launcher scripts when root/bin dir does not exist
On 29/08/2016 14:28, Sundararajan Athijegannathan wrote: Updated: http://cr.openjdk.java.net/~sundar/8159004/webrev.02/ -Sundar This looks okay to me. -Alan
Re: Review Request: JDK-8160851: Remove old module-related options
After further discussion off line we are aiming to get the fix for JDK-8163316 into this week's build of jdk-9+134. -- Kevin Mandy Chung wrote: On Aug 26, 2016, at 4:17 PM, Kevin Rushforth wrote: Hi Mandy, How soon were you thinking to push this to 9-dev? Until we change JavaFX to use the new options, which is planned to go into our dev repo on Monday for the following week's promoted build (b135) So JDK-8163316 does not make b134 (that’s what I thought it’s target for)? I initially plan to push this next Tuesday for jdk-9+135 integration, specifically for JDK-8163316. so if you push the changes to jdk9/dev before build 135 is promoted, it will break JavaFX. Noted. I’ll follow up with you. Mandy The following is tracking the FX changes: https://bugs.openjdk.java.net/browse/JDK-8163316 -- Kevin Mandy Chung wrote: This patch removes the old module options from java, javac, javadoc, etc. The new options are in jdk-9+132 [1]. I did a scan on the jdk9/dev forest to replace any remaining reference to the old options. I find some tests in jdk9/hs/hotspot using the old options that I will file a separate issue. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160851/webrev.00/index.html Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009025.html
Re: RFR 8159004: jlink attempts to create launcher scripts when root/bin dir does not exist
Updated: http://cr.openjdk.java.net/~sundar/8159004/webrev.02/ -Sundar On 8/29/2016 5:52 PM, Alan Bateman wrote: > On 29/08/2016 13:00, Sundararajan Athijegannathan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8159004/webrev.01/ >> for https://bugs.openjdk.java.net/browse/JDK-8159004 >> >> Piggybacking couple of cleanups suggested (but missed) in this thread >> -> >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009186.html > In storeFiles then you could move "Path bin = ..." to the enclosing > scope and avoid a bit of duplications, otherwise looks good. > > -Alan
Re: RFR 8159004: jlink attempts to create launcher scripts when root/bin dir does not exist
On 29/08/2016 13:00, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8159004/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8159004 Piggybacking couple of cleanups suggested (but missed) in this thread -> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009186.html In storeFiles then you could move "Path bin = ..." to the enclosing scope and avoid a bit of duplications, otherwise looks good. -Alan
Re: RFR: JDK-8161000 - GPL header incorrect - classfile/classpath
On 29/08/2016 13:16, Jim Laskey (Oracle) wrote: On behalf of Swamy http://cr.openjdk.java.net/~jlaskey/8161000/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8161000 +1
Re: RFR 8159004: jlink attempts to create launcher scripts when root/bin dir does not exist
+1 > On Aug 29, 2016, at 9:00 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8159004/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8159004 > > Piggybacking couple of cleanups suggested (but missed) in this thread -> > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009186.html > > > Thanks, > -Sundar
Re: RFR 8164800: Cross targeting Windows
Fixing along with another fix -> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009210.html Thanks -Sundar On 8/26/2016 9:56 PM, Remi Forax wrote: > Hi Sundararajan, > Also, in createArgs(), instead Collections.unmodifiableList(), you can use > List.of(). > > regards, > Rémi > > - Mail original - >> De: "Sundararajan Athijegannathan" >> À: "Alan Bateman" , "jigsaw-dev" >> >> Envoyé: Vendredi 26 Août 2016 18:08:12 >> Objet: Re: RFR 8164800: Cross targeting Windows >> Hmm.. I saw another RuntimeException in the same file for another issue.. >> >> I guess I'll have to deal with this change when doing another fix in >> that file - I do have one for reading java.version from java.base >> descriptor. I'll clean it up when doing that fix. >> >> -Sundar >> >> >> On 8/26/2016 9:37 PM, Alan Bateman wrote: >>> >>> On 26/08/2016 15:54, Sundararajan Athijegannathan wrote: Hi, Fixed as suggested: http://cr.openjdk.java.net/~sundar/8164800/webrev.02/ * Field name changed to targetOsName * Throwing RuntimeException if os name can't be determined from java.base >>> This looks okay except for RuntimeException, should this be >>> PlugException with an appropriate cause? Also for the message then it >>> would be better to say that the TargetPlatform attribute is missing >>> from the java.base module. >>> >>> -Alan
RFR 8159004: jlink attempts to create launcher scripts when root/bin dir does not exist
Please review http://cr.openjdk.java.net/~sundar/8159004/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8159004 Piggybacking couple of cleanups suggested (but missed) in this thread -> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009186.html Thanks, -Sundar
