Re: Jigsaw @ JavaOne 2015

2015-10-28 Thread Remi Forax
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

Re: RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV

2015-10-28 Thread Alan Bateman
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:

Re: Jigsaw @ JavaOne 2015

2015-10-28 Thread Paul Benedict
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,

RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV

2015-10-28 Thread Roger Riggs
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:

Re: RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV

2015-10-28 Thread Roger Riggs
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

Re: Jigsaw @ JavaOne 2015

2015-10-28 Thread 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

Re: Jigsaw @ JavaOne 2015

2015-10-28 Thread Mario Torre
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

Re: Jigsaw @ JavaOne 2015

2015-10-28 Thread Remi Forax
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

Re: Jigsaw @ JavaOne 2015

2015-10-28 Thread Tim Boudreau
+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

Re: Jigsaw @ JavaOne 2015

2015-10-28 Thread Stephen Colebourne
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

Avoiding same-package conflicts

2015-10-28 Thread Karl Sanders
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

Compilation feedback and version question

2015-10-28 Thread Stephen Colebourne
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

Re: Jigsaw @ JavaOne 2015

2015-10-28 Thread Remi Forax
- 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

Re: Compilation feedback and version question

2015-10-28 Thread Alex Buckley
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:

Re: Jigsaw @ JavaOne 2015

2015-10-28 Thread Paul Benedict
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

Re: Avoiding same-package conflicts

2015-10-28 Thread Alex Buckley
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

Re: Jigsaw @ JavaOne 2015

2015-10-28 Thread Remi Forax
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

Re: Compilation feedback and version question

2015-10-28 Thread Jonathan Gibbons
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