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 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

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:
   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

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, 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/
> >
>


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:
   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

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 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

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 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 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 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

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 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

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 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: 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 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. 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


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 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

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
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

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 :
> > 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

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:
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

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 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

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 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

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 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

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 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