Re: Jigsaw @ JavaOne 2015
Hi Marrio, When creating a new application, using the prefix of the packages as name for a module seems intuitive and using '_' instead of '.' as separator inside the module name avoid the unecessary confusion for a human between a package and a module with the same name, it's just a code convention. When retrofitting an old application, like by example the JDK, you will group packages that have no a common prefix name or the common prefix can be used for several modules, in that case, having a module named java.base but no package java.base.something seems counter intuitive, using '_' instead of '.' make clear that a module name is just a name. regards, Rémi - Mail original - > De: "Mario Torre"> À: "Paul Benedict" > Cc: jigsaw-dev@openjdk.java.net > Envoyé: Mardi 27 Octobre 2015 23:41:05 > Objet: Re: Jigsaw @ JavaOne 2015 > > 2015-10-27 22:13 GMT+01:00 Paul Benedict : > > Thanks Mark. Great slides. I'd just like to throw out my impression (again) > > that module names with dots look like packages. How receptive is the EG to > > changing it to underscores? > > I think that this is the exact point, mapping to package seems quite > intuitive as it represents directly the content of the module. > > Cheers, > Mario > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ >
Re: RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV
On 28/10/2015 06:40, Roger Riggs wrote: Please review an update to the jimage reader implementation to correct the case where a class name is very long causing a SEGV due to buffer overruns. The fix will be pushed to the hs-comp repo; the bug was first spotted there. Webrev: http://cr.openjdk.java.net/~rriggs//webrev-jimage-segv-8139390 Issue: https://bugs.openjdk.java.net/browse/JDK-8139390 The new ThrowByName reminded me to ask if jni_util.h is needed. As libjimage doesn't link to libjava then there won't be any dependences but perhaps some of the macros are used? -Alan
Re: Jigsaw @ JavaOne 2015
Yes, and if module identifiers can be specified in the source code natively (i.e., literals without strings), then they will fit into the current syntax for Java identifiers [1]. [1] https://docs.oracle.com/cd/E19798-01/821-1841/bnbuk/index.html Cheers, Paul On Wed, Oct 28, 2015 at 6:56 AM, Remi Foraxwrote: > Hi Marrio, > > When creating a new application, using the prefix of the packages as name > for a module seems intuitive and using '_' instead of '.' as separator > inside the module name avoid the unecessary confusion for a human between a > package and a module with the same name, it's just a code convention. > > When retrofitting an old application, like by example the JDK, you will > group packages that have no a common prefix name or the common prefix can > be used for several modules, in that case, having a module named java.base > but no package java.base.something seems counter intuitive, using '_' > instead of '.' make clear that a module name is just a name. > > regards, > Rémi > > - Mail original - > > De: "Mario Torre" > > À: "Paul Benedict" > > Cc: jigsaw-dev@openjdk.java.net > > Envoyé: Mardi 27 Octobre 2015 23:41:05 > > Objet: Re: Jigsaw @ JavaOne 2015 > > > > 2015-10-27 22:13 GMT+01:00 Paul Benedict : > > > Thanks Mark. Great slides. I'd just like to throw out my impression > (again) > > > that module names with dots look like packages. How receptive is the > EG to > > > changing it to underscores? > > > > I think that this is the exact point, mapping to package seems quite > > intuitive as it represents directly the content of the module. > > > > Cheers, > > Mario > > > > -- > > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > > Proud GNU Classpath developer: http://www.classpath.org/ > > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > > > Please, support open standards: > > http://endsoftpatents.org/ > > >
RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV
Please review an update to the jimage reader implementation to correct the case where a class name is very long causing a SEGV due to buffer overruns. The fix will be pushed to the hs-comp repo; the bug was first spotted there. Webrev: http://cr.openjdk.java.net/~rriggs//webrev-jimage-segv-8139390 Issue: https://bugs.openjdk.java.net/browse/JDK-8139390 Thanks, Roger
Re: RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV
Hi Alan, Yes, it uses the JNU_CHECK_EXCEPTION_RETURN macros. If it would be cleaner to remove the jni_util.h include, the macros can be replaced. They don't add much value in this case. Thanks, Roger On 10/28/15 8:15 AM, Alan Bateman wrote: On 28/10/2015 06:40, Roger Riggs wrote: Please review an update to the jimage reader implementation to correct the case where a class name is very long causing a SEGV due to buffer overruns. The fix will be pushed to the hs-comp repo; the bug was first spotted there. Webrev: http://cr.openjdk.java.net/~rriggs//webrev-jimage-segv-8139390 Issue: https://bugs.openjdk.java.net/browse/JDK-8139390 The new ThrowByName reminded me to ask if jni_util.h is needed. As libjimage doesn't link to libjava then there won't be any dependences but perhaps some of the macros are used? -Alan
Re: Jigsaw @ JavaOne 2015
We've been (with JBoss Modules and thus our various application server offerings) using module name conventions that match package names for several years, and the number of people who have actually been confused by it to my knowledge is exactly zero. The actual problem is probably quite overstated. People just don't seem to have trouble with this (nor do people generally seem to get confused by, for example, a C++ library name being the same as the root C++ namespace used by that library, to draw another language equivalent). On 10/28/2015 06:56 AM, Remi Forax wrote: Hi Marrio, When creating a new application, using the prefix of the packages as name for a module seems intuitive and using '_' instead of '.' as separator inside the module name avoid the unecessary confusion for a human between a package and a module with the same name, it's just a code convention. When retrofitting an old application, like by example the JDK, you will group packages that have no a common prefix name or the common prefix can be used for several modules, in that case, having a module named java.base but no package java.base.something seems counter intuitive, using '_' instead of '.' make clear that a module name is just a name. regards, Rémi - Mail original - De: "Mario Torre"À: "Paul Benedict" Cc: jigsaw-dev@openjdk.java.net Envoyé: Mardi 27 Octobre 2015 23:41:05 Objet: Re: Jigsaw @ JavaOne 2015 2015-10-27 22:13 GMT+01:00 Paul Benedict : Thanks Mark. Great slides. I'd just like to throw out my impression (again) that module names with dots look like packages. How receptive is the EG to changing it to underscores? I think that this is the exact point, mapping to package seems quite intuitive as it represents directly the content of the module. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ -- - DML
Re: Jigsaw @ JavaOne 2015
2015-10-28 17:59 GMT+01:00 David M. Lloyd: > We've been (with JBoss Modules and thus our various application server > offerings) using module name conventions that match package names for > several years, and the number of people who have actually been confused by > it to my knowledge is exactly zero. > > The actual problem is probably quite overstated. People just don't seem to > have trouble with this (nor do people generally seem to get confused by, for > example, a C++ library name being the same as the root C++ namespace used by > that library, to draw another language equivalent). Also, underscores in Java read weird :) Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/
Re: Jigsaw @ JavaOne 2015
Hi David, - Mail original - > De: "David M. Lloyd"> À: jigsaw-dev@openjdk.java.net > Envoyé: Mercredi 28 Octobre 2015 17:59:08 > Objet: Re: Jigsaw @ JavaOne 2015 > > We've been (with JBoss Modules and thus our various application server > offerings) using module name conventions that match package names for > several years, and the number of people who have actually been confused > by it to my knowledge is exactly zero. Yes, but JBoss module descriptor, by default, doesn't mix package names and module names while Java module descriptor (module-info) does. > > The actual problem is probably quite overstated. People just don't seem > to have trouble with this (nor do people generally seem to get confused > by, for example, a C++ library name being the same as the root C++ > namespace used by that library, to draw another language equivalent). This problem was first reported by Mani from the LondonJUG and since i've experencied the same issue with graduated students. At JTRES, i've reused the same presentation but convert all '.' to '_' in module names and i had no question at all on that subject. that said, i think we should support '.' in module name to respect JBoss/OSGI convention even if the official Java coding convention is to use '_' in module name. regards, Rémi > > On 10/28/2015 06:56 AM, Remi Forax wrote: > > Hi Marrio, > > > > When creating a new application, using the prefix of the packages as name > > for a module seems intuitive and using '_' instead of '.' as separator > > inside the module name avoid the unecessary confusion for a human between > > a package and a module with the same name, it's just a code convention. > > > > When retrofitting an old application, like by example the JDK, you will > > group packages that have no a common prefix name or the common prefix can > > be used for several modules, in that case, having a module named java.base > > but no package java.base.something seems counter intuitive, using '_' > > instead of '.' make clear that a module name is just a name. > > > > regards, > > Rémi > > > > - Mail original - > >> De: "Mario Torre" > >> À: "Paul Benedict" > >> Cc: jigsaw-dev@openjdk.java.net > >> Envoyé: Mardi 27 Octobre 2015 23:41:05 > >> Objet: Re: Jigsaw @ JavaOne 2015 > >> > >> 2015-10-27 22:13 GMT+01:00 Paul Benedict : > >>> Thanks Mark. Great slides. I'd just like to throw out my impression > >>> (again) > >>> that module names with dots look like packages. How receptive is the EG > >>> to > >>> changing it to underscores? > >> > >> I think that this is the exact point, mapping to package seems quite > >> intuitive as it represents directly the content of the module. > >> > >> Cheers, > >> Mario > >> > >> -- > >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > >> > >> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > >> Proud GNU Classpath developer: http://www.classpath.org/ > >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > >> > >> Please, support open standards: > >> http://endsoftpatents.org/ > >> > > -- > - DML >
Re: Jigsaw @ JavaOne 2015
+1 - people have been using . as a delimiter for maven groupId and artifactId names for years, and I've never heard of someone's head exploding as a result. Similarly, NetBeans module system has used . as a delimiter since 2000, and I don't recall ever seeing a message on the mailing lists (which I've been on since '99 and am still active on) having a problem with it. -Tim On Wed, Oct 28, 2015 at 12:59 PM, David M. Lloydwrote: > We've been (with JBoss Modules and thus our various application server > offerings) using module name conventions that match package names for > several years, and the number of people who have actually been confused by > it to my knowledge is exactly zero. > > The actual problem is probably quite overstated. People just don't seem > to have trouble with this (nor do people generally seem to get confused by, > for example, a C++ library name being the same as the root C++ namespace > used by that library, to draw another language equivalent). > > > On 10/28/2015 06:56 AM, Remi Forax wrote: > >> Hi Marrio, >> >> When creating a new application, using the prefix of the packages as name >> for a module seems intuitive and using '_' instead of '.' as separator >> inside the module name avoid the unecessary confusion for a human between a >> package and a module with the same name, it's just a code convention. >> >> When retrofitting an old application, like by example the JDK, you will >> group packages that have no a common prefix name or the common prefix can >> be used for several modules, in that case, having a module named java.base >> but no package java.base.something seems counter intuitive, using '_' >> instead of '.' make clear that a module name is just a name. >> >> regards, >> Rémi >> >> - Mail original - >> >>> De: "Mario Torre" >>> À: "Paul Benedict" >>> Cc: jigsaw-dev@openjdk.java.net >>> Envoyé: Mardi 27 Octobre 2015 23:41:05 >>> Objet: Re: Jigsaw @ JavaOne 2015 >>> >>> 2015-10-27 22:13 GMT+01:00 Paul Benedict : >>> Thanks Mark. Great slides. I'd just like to throw out my impression (again) that module names with dots look like packages. How receptive is the EG to changing it to underscores? >>> >>> I think that this is the exact point, mapping to package seems quite >>> intuitive as it represents directly the content of the module. >>> >>> Cheers, >>> Mario >>> >>> -- >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>> >>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >>> Proud GNU Classpath developer: http://www.classpath.org/ >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>> >>> Please, support open standards: >>> http://endsoftpatents.org/ >>> >>> > -- > - DML > -- http://timboudreau.com
Re: Jigsaw @ JavaOne 2015
I've also been somewhat concerned that the two namespaces are similar, but concluded that it is best that way. Using underscores, dashes or anything else would be more confusing, given that the emphasis is on a namespace concept within the JLS. I do find remembering which is which, module vs package, in module-info.java is a little confusing, but I suspect we'll get used to it. I wouldn't object to using "requires module com.foo.bar" however. I'm more concerned about some other aspects of the module spec, which I'm still pondering. Stephen On 28 October 2015 at 16:59, David M. Lloydwrote: > We've been (with JBoss Modules and thus our various application server > offerings) using module name conventions that match package names for > several years, and the number of people who have actually been confused by > it to my knowledge is exactly zero. > > The actual problem is probably quite overstated. People just don't seem to > have trouble with this (nor do people generally seem to get confused by, for > example, a C++ library name being the same as the root C++ namespace used by > that library, to draw another language equivalent). > > > On 10/28/2015 06:56 AM, Remi Forax wrote: >> >> Hi Marrio, >> >> When creating a new application, using the prefix of the packages as name >> for a module seems intuitive and using '_' instead of '.' as separator >> inside the module name avoid the unecessary confusion for a human between a >> package and a module with the same name, it's just a code convention. >> >> When retrofitting an old application, like by example the JDK, you will >> group packages that have no a common prefix name or the common prefix can be >> used for several modules, in that case, having a module named java.base but >> no package java.base.something seems counter intuitive, using '_' instead of >> '.' make clear that a module name is just a name. >> >> regards, >> Rémi >> >> - Mail original - >>> >>> De: "Mario Torre" >>> À: "Paul Benedict" >>> Cc: jigsaw-dev@openjdk.java.net >>> Envoyé: Mardi 27 Octobre 2015 23:41:05 >>> Objet: Re: Jigsaw @ JavaOne 2015 >>> >>> 2015-10-27 22:13 GMT+01:00 Paul Benedict : Thanks Mark. Great slides. I'd just like to throw out my impression (again) that module names with dots look like packages. How receptive is the EG to changing it to underscores? >>> >>> >>> I think that this is the exact point, mapping to package seems quite >>> intuitive as it represents directly the content of the module. >>> >>> Cheers, >>> Mario >>> >>> -- >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>> >>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >>> Proud GNU Classpath developer: http://www.classpath.org/ >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>> >>> Please, support open standards: >>> http://endsoftpatents.org/ >>> > > -- > - DML
Avoiding same-package conflicts
Hi, I'm trying out the JDK 9 EA with Jigsaw. I created two modules, A and B, which are required by module C. Modules A and B contain a non-exported package with the same name. After compiling each module separately I start module C and get a java.lang.reflect.LayerInstantiationException saying that modules A and B contain a package with the same name. In light of this behaviour I have two questions. - Is it correct to say that for a simple Java SE application to work with this configuration the only solution, in the realm of what will be provided with the GA version of JDK 9, is through the concept of layers of modules? - In that case will there be some sort of out-of-the box functionality to have this scenario work or will I have to write some non-trivial code to manage these layers? In other words, I have to use different versions of the same library in a Java SE application. Since Jigsaw is approaching I thought I could wait for it instead of learning and having to deal with OSGi. But from what I see by using only Jigsaw I won't be able to satisfy this requirement. At least not without writing some non-trivial code that I'm afraid is above my skill level. Cheers, Karl
Compilation feedback and version question
I can confirm that the current EA build 1.9.0-ea-jigsaw-nightly-h3660-20151022-b86 allowed a successful build using maven (with tests) of the OpenGamma test case, which is a step forward from when I last tried it. When running "java -listmods" I get outpuy including this: java.base@9.0 java.compact1@9.0 java.compact2@9.0 java.compact3@9.0 java.compiler@9.0 java.corba@9.0 But when I look at the JDK source module-info.java file: http://hg.openjdk.java.net/jigsaw/jake/jdk/file/1b632228f7e5/src/java.base/share/classes/module-info.java It does not contain the version number "9.0". Where is the version coming from? It is weird to see the version number so closely associated with the module in -listmods when so much of the mood music of the current Jigsaw work is that the version is "not our problem guv". Stephen
Re: Jigsaw @ JavaOne 2015
- Mail original - > De: "Mario Torre"> À: "David M. Lloyd" > Cc: jigsaw-dev@openjdk.java.net > Envoyé: Mercredi 28 Octobre 2015 18:10:34 > Objet: Re: Jigsaw @ JavaOne 2015 > > 2015-10-28 17:59 GMT+01:00 David M. Lloyd : > > We've been (with JBoss Modules and thus our various application server > > offerings) using module name conventions that match package names for > > several years, and the number of people who have actually been confused by > > it to my knowledge is exactly zero. > > > > The actual problem is probably quite overstated. People just don't seem to > > have trouble with this (nor do people generally seem to get confused by, > > for > > example, a C++ library name being the same as the root C++ namespace used > > by > > that library, to draw another language equivalent). > > Also, underscores in Java read weird :) > > Cheers, > Mario yes, but with another separator it's worst (i know, it's not a real argument) with dots: (not obvious if it refers a package or a module) org.objectweb.asm, with dash: org-objectweb-asm, with underscores: org_objectweb_asm, with tilda: org~objectweb~asm with star: (this will cause trouble in shells) org*objectweb*asm with colon: org:objectweb:asm with double colons: org::objectweb::asm with bang: org!objectweb!asm any other idea ? cheers, Rémi > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ >
Re: Compilation feedback and version question
On 10/28/2015 11:57 AM, Stephen Colebourne wrote: When running "java -listmods" I get outpuy including this: java.base@9.0 java.compact1@9.0 java.compact2@9.0 java.compact3@9.0 java.compiler@9.0 java.corba@9.0 But when I look at the JDK source module-info.java file: http://hg.openjdk.java.net/jigsaw/jake/jdk/file/1b632228f7e5/src/java.base/share/classes/module-info.java It does not contain the version number "9.0". Where is the version coming from? The 'jar' invocation that built the modular JARs that were subsequently jlink'ed into the image. In the "Advanced Modular Development" slides at http://openjdk.java.net/projects/jigsaw/j1/, see the "Library Migration" section and in particular the slide numbered 30. Alex
Re: Jigsaw @ JavaOne 2015
Tim, but Maven doesn't have a native concept of packages. That's a compiler concern, and now Java's compiler will have both package names and module names both with dots? I think that is confusing. A package is a properly nested naming structure... but a module is just a simple name. Correct me if wrong, but modules can't bundle nested modules, right? If it can't, then using dots is more problematic than it's worth. That's why I recommend it follow the standard Java identifier rules where underscores are the preferred separator. On Oct 28, 2015 2:43 PM, "Tim Boudreau"wrote: > +1 - people have been using . as a delimiter for maven groupId and > artifactId names for years, and I've never heard of someone's head > exploding as a result. > > Similarly, NetBeans module system has used . as a delimiter since 2000, and > I don't recall ever seeing a message on the mailing lists (which I've been > on since '99 and am still active on) having a problem with it. > > -Tim > > > On Wed, Oct 28, 2015 at 12:59 PM, David M. Lloyd > wrote: > > > We've been (with JBoss Modules and thus our various application server > > offerings) using module name conventions that match package names for > > several years, and the number of people who have actually been confused > by > > it to my knowledge is exactly zero. > > > > The actual problem is probably quite overstated. People just don't seem > > to have trouble with this (nor do people generally seem to get confused > by, > > for example, a C++ library name being the same as the root C++ namespace > > used by that library, to draw another language equivalent). > > > > > > On 10/28/2015 06:56 AM, Remi Forax wrote: > > > >> Hi Marrio, > >> > >> When creating a new application, using the prefix of the packages as > name > >> for a module seems intuitive and using '_' instead of '.' as separator > >> inside the module name avoid the unecessary confusion for a human > between a > >> package and a module with the same name, it's just a code convention. > >> > >> When retrofitting an old application, like by example the JDK, you will > >> group packages that have no a common prefix name or the common prefix > can > >> be used for several modules, in that case, having a module named > java.base > >> but no package java.base.something seems counter intuitive, using '_' > >> instead of '.' make clear that a module name is just a name. > >> > >> regards, > >> Rémi > >> > >> - Mail original - > >> > >>> De: "Mario Torre" > >>> À: "Paul Benedict" > >>> Cc: jigsaw-dev@openjdk.java.net > >>> Envoyé: Mardi 27 Octobre 2015 23:41:05 > >>> Objet: Re: Jigsaw @ JavaOne 2015 > >>> > >>> 2015-10-27 22:13 GMT+01:00 Paul Benedict : > >>> > Thanks Mark. Great slides. I'd just like to throw out my impression > (again) > that module names with dots look like packages. How receptive is the > EG > to > changing it to underscores? > > >>> > >>> I think that this is the exact point, mapping to package seems quite > >>> intuitive as it represents directly the content of the module. > >>> > >>> Cheers, > >>> Mario > >>> > >>> -- > >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > >>> > >>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > >>> Proud GNU Classpath developer: http://www.classpath.org/ > >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > >>> > >>> Please, support open standards: > >>> http://endsoftpatents.org/ > >>> > >>> > > -- > > - DML > > > > > > -- > http://timboudreau.com >
Re: Avoiding same-package conflicts
Hi Karl, Serious question: does your Java SE application expect that different versions of the same library are placed on the classpath in JDK 8? Alex On 10/28/2015 1:34 PM, Karl Sanders wrote: Hi, I'm trying out the JDK 9 EA with Jigsaw. I created two modules, A and B, which are required by module C. Modules A and B contain a non-exported package with the same name. After compiling each module separately I start module C and get a java.lang.reflect.LayerInstantiationException saying that modules A and B contain a package with the same name. In light of this behaviour I have two questions. - Is it correct to say that for a simple Java SE application to work with this configuration the only solution, in the realm of what will be provided with the GA version of JDK 9, is through the concept of layers of modules? - In that case will there be some sort of out-of-the box functionality to have this scenario work or will I have to write some non-trivial code to manage these layers? In other words, I have to use different versions of the same library in a Java SE application. Since Jigsaw is approaching I thought I could wait for it instead of learning and having to deal with OSGi. But from what I see by using only Jigsaw I won't be able to satisfy this requirement. At least not without writing some non-trivial code that I'm afraid is above my skill level. Cheers, Karl
Re: Jigsaw @ JavaOne 2015
Hi Stephen, - Mail original - > De: "Stephen Colebourne"> À: jigsaw-dev@openjdk.java.net > Envoyé: Mercredi 28 Octobre 2015 19:48:13 > Objet: Re: Jigsaw @ JavaOne 2015 > > I've also been somewhat concerned that the two namespaces are similar, > but concluded that it is best that way. Using underscores, dashes or > anything else would be more confusing, given that the emphasis is on a > namespace concept within the JLS. Not sure i'm convinced by this argument, Java uses several namespaces but we, human, use to use different naming conventions. If we introduce '_' it will just a naming convention like the others. > > I do find remembering which is which, module vs package, in > module-info.java is a little confusing, but I suspect we'll get used > to it. I wouldn't object to using "requires module com.foo.bar" > however. yes, that the other option. It's not very java-ish, Java uses keyword when you define something not when you use it, unlike Ruby or Perl. Thinking a little more about that, there is another place where using dot in module name is weird, the proposed layout of a Java project. The module name is a folder name, so modules like com.foo.image.gif or com.bar.language.java will cause trouble with something as simple as the command ls. > > I'm more concerned about some other aspects of the module spec, which > I'm still pondering. > > Stephen Rémi > > > On 28 October 2015 at 16:59, David M. Lloyd wrote: > > We've been (with JBoss Modules and thus our various application server > > offerings) using module name conventions that match package names for > > several years, and the number of people who have actually been confused by > > it to my knowledge is exactly zero. > > > > The actual problem is probably quite overstated. People just don't seem to > > have trouble with this (nor do people generally seem to get confused by, > > for > > example, a C++ library name being the same as the root C++ namespace used > > by > > that library, to draw another language equivalent). > > > > > > On 10/28/2015 06:56 AM, Remi Forax wrote: > >> > >> Hi Marrio, > >> > >> When creating a new application, using the prefix of the packages as name > >> for a module seems intuitive and using '_' instead of '.' as separator > >> inside the module name avoid the unecessary confusion for a human between > >> a > >> package and a module with the same name, it's just a code convention. > >> > >> When retrofitting an old application, like by example the JDK, you will > >> group packages that have no a common prefix name or the common prefix can > >> be > >> used for several modules, in that case, having a module named java.base > >> but > >> no package java.base.something seems counter intuitive, using '_' instead > >> of > >> '.' make clear that a module name is just a name. > >> > >> regards, > >> Rémi > >> > >> - Mail original - > >>> > >>> De: "Mario Torre" > >>> À: "Paul Benedict" > >>> Cc: jigsaw-dev@openjdk.java.net > >>> Envoyé: Mardi 27 Octobre 2015 23:41:05 > >>> Objet: Re: Jigsaw @ JavaOne 2015 > >>> > >>> 2015-10-27 22:13 GMT+01:00 Paul Benedict : > > Thanks Mark. Great slides. I'd just like to throw out my impression > (again) > that module names with dots look like packages. How receptive is the EG > to > changing it to underscores? > >>> > >>> > >>> I think that this is the exact point, mapping to package seems quite > >>> intuitive as it represents directly the content of the module. > >>> > >>> Cheers, > >>> Mario > >>> > >>> -- > >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > >>> > >>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > >>> Proud GNU Classpath developer: http://www.classpath.org/ > >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > >>> > >>> Please, support open standards: > >>> http://endsoftpatents.org/ > >>> > > > > -- > > - DML >
Re: Compilation feedback and version question
On 10/28/2015 01:50 PM, Stephen Colebourne wrote: Finally, I had my module-info.java in the wrong folder initially (at the org.joda.convert package level, rather than the root). However, it got picked up and compiled into the root of the output classes folder. I guess this is expected, but I found it confusing. It might be better to insist that module-info.java must be at the root, and stop javac if it is found in another folder. Stephen Maybe it is surprising, but right now, if you list all the necessary files on the command line, javac does not impose any requirement on the organization of any of those files. This applies to plain-old-.java files as well as module-info.java files. The requirements for organizing source files only come into play when javac tries to look up files on the source path. -- Jon