Help Unsubscribe me from this chain
Peeyush Maharshi
peeyush.m at gmail.com
Sat Feb 4 04:42:36 UTC 2017
On Feb 3, 2017 10:04 PM, <jigsaw-dev-request at openjdk.java.net> wrote:
Send jigsaw-dev mailing list submissions to
jigsaw-dev at openjdk.java.net
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev
or, via email, send a message with subject or body 'help' to
jigsaw-dev-request at openjdk.java.net
You can reach the person managing the list at
jigsaw-dev-owner at openjdk.java.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of jigsaw-dev digest..."
Today's Topics:
1. Re: Automatic module names (Robert Scholte)
2. hg: jigsaw/jake/jdk: 2 new changesets (alan.bateman at oracle.com)
3. Re: Automatic module names (David M. Lloyd)
4. Re: Automatic module names (Andrew Dinn)
5. Re: Automatic module names (Alan Bateman)
6. Re: Automatic module names - "requires package" proposal
(Stephen Colebourne)
----------------------------------------------------------------------
Message: 1
Date: Fri, 03 Feb 2017 12:44:38 +0100
From: "Robert Scholte" <rfscholte at apache.org>
To: jigsaw-dev at openjdk.java.net
Subject: Re: Automatic module names
Message-ID: <op.yu21kog4kdkhrr at desktop-2khsk44>
Content-Type: text/plain; charset=iso-8859-15; format=flowed;
delsp=yes
Hi Nicolai,
let's consider that my project depends on the following dependencies:
com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed.
I somehow want to have them both as requirements:
module M.N {
requires static library; // com.foo.bar:library
requires library; // com.acme:library
}
How can I define that the 'requires static library' should be mapped to
com.foo.bar:library:1.0 on the modulepath, while 'requires library' should
be mapped to com.acme:library:2.3.1
One ugly solution would be:
requires static library containing com.foo.bar.baz.SomeClass;
requires library containing acme.AnotherClass;
We should really wonder if ease-of-transition is worth the minefield we're
creating with the introduction of automodules. IMHO all options we're
trying to add to keep automodules will only over-complicate things, not
even being sure if all edges are covered.
thanks,
Robert
On Thu, 02 Feb 2017 12:28:13 +0100, Nicolai Parlog <nipa at codefx.org> wrote:
> Hi everyone,
>
> after thinking about this a little longer, I came to the conclusion that
> compile-time/launch-time aliasing might be the only way out of this (at
> least the only I could come up with) that keeps automatic modules alive
> and does not introduce a conceptual dependency on Maven.
>
> The idea:
>
> A command line option, let's say `--alias-modules A=X`, maps module name
> A to module name X. Every dependency on either A or X will be resolved
> to X, implying that there must a module X in the universe of observable
> modules. There can be several aliases for the same module
> (`--alias-modules A=X,B=X`; X needs to be observable) and they can be
> chained (`--alias-modules A=X,X=Y`; Y needs to be observable)
>
> Aliasing would of course have to be applied to qualified exports, opens,
> and similar mechanisms as well.
>
> It might be worth adding the rule that no observable module must have an
> aliased name. So for `--alias-modules A=X` there must be no observable
> module A. This prevents ambiguity and would effectively prevent aliasing
> platform modules. That might be a good thing because it looks like
> aliasing and upgrading modules has quite some overlap (or is even
> identical?)
>
> Unfortunately I could not come up with a way to limit aliasing to
> automatic module names (in case that were desirable) without somehow
> marking dependencies on automatic modules, likely in the module
> declaration. If changing module declaration syntax is still on the
> table, it could be changed so that dependencies on automatic modules
> must be phrased as something like `requires automatic`.
>
> The obvious semantics would be that only such requires clauses can be
> fulfilled with automatic modules and that only such dependencies could
> be aliased (this might make it prudent to phrase the aliasing option
> accordingly, e.g. `--alias-automatic-modules`).
>
> This could also be used to help developers in keeping their module
> declarations clean: The compiler could to emit a warning if a `requires
> automatic` clause is fulfilled by a regular module.
>
> I would love to hear some thoughts on this idea, even if it considered
> to be stupid, impractical,etc. :)
>
> so long ... Nicolai
>
>
>
> On 27.01.2017 15:11, Stephen Colebourne wrote:
>> Back in October, I raised the issue of modules names generally and for
>> automatic modules specifically [1]. The short thread came to no
>> conclusion, but recent threads have again raised similar problems. The
>> problem is that automatic modules have magical name creation from a
>> filename, which is brittle and unlike anything else in Java.
>>
>> I also recently looked at the Joda-Convert and Joda-Beans libraries,
>> to see if I could add module-info in preparation for Java 9. I quickly
>> backed away, again because of the same issue. Put simply, I am
>> unwilling to write a module-info file that refers to a dependency that
>> is not yet a module. And I have to advise all open source projects to
>> do the same. Given this, there can be no simple migration to the JPMS
>> for open source projects. Each open source project must wait for all
>> its dependencies to migrate to JPMS (by adding a module-info and
>> publishing to Maven Central).
>>
>> The issue is clear. If I write this:
>>
>> module org.joda.convert {
>> requires guava;
>> }
>>
>> where guava is an automatic module, I am locking in the name of the
>> guava dependency, something that I do not control. The name "guava" is
>> just a guess. The guava authors might choose "com.google.guava" or
>> something else entirely.
>>
>> In a closed system of modules, ie. a private application, automatic
>> modules are fine, because the requires clause can be changed if it
>> turns out the guess was wrong. But once published as an open source
>> project to Maven Central or elsewhere, the guess cannot be fixed if it
>> is wrong (without releasing a new version of the library, which is not
>> an acceptable solution).
>>
>> I also strongly believe that module names cannot be flat and
>> unstructured, such as "joda-convert" or "guava". They must have
>> structure, such as the domain name or a Maven-style group name
>> "org.joda.convert" or "org.joda:joda-convert". The potential for
>> clashes has been shown by the Maven team [2].
>>
>> Some brainstormed possible changes:
>>
>> - Remove the automatic module concept altogether
>>
>> - Define a clear mapping from Maven Central co-ordinates to module
>> name that includes the group, artifact and classifier
>>
>> - Provide a text file to JPMS that allows incorrect module names to be
>> mapped to the correct name
>>
>> - Publicly advise against using automatic modules for open source
>> projects
>>
>> - Change rules of Maven Central to prevent modular jars being added
>> that depend on an automatic module
>>
>> - Allow requires clauses to have aliases - requires org.guava.guava OR
>> guava.
>>
>> - Allow modules to have aliases - module org.guava.guava AKA guava
>>
>>
>> Given that applications can depend on libraries that haven't been
>> released in years, this has the potential to be a critical problem for
>> the ecosystem. My preference remains to define a clear mapping from
>> the widely adopted Maven Central naming strategy to JPMS modules.
>> Ideally, this would be a formal group concept in the JPMS, something
>> that I believe is sorely lacking.
>>
>> Stephen
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-
October/009631.html
>> [2]
>> http://mail.openjdk.java.net/pipermail/jpms-spec-observers/
2017-January/000707.html
>>
------------------------------
Message: 2
Date: Fri, 03 Feb 2017 12:07:09 +0000
From: alan.bateman at oracle.com
To: jigsaw-dev at openjdk.java.net
Subject: hg: jigsaw/jake/jdk: 2 new changesets
Message-ID: <201702031207.v13C79kt021495 at aojmv0008.oracle.com>
Changeset: a0a6f078fefe
Author: alanb
Date: 2017-02-03 12:06 +0000
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0a6f078fefe
Tighten up ModuleReader for exploded modules
! src/java.base/share/classes/java/lang/module/ModuleReader.java
! src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java
! test/java/lang/module/ModuleReader/ModuleReaderTest.java
Changeset: ee81e3ab4655
Author: alanb
Date: 2017-02-03 12:06 +0000
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee81e3ab4655
Minor SL javadoc update
! src/java.base/share/classes/java/util/ServiceLoader.java
------------------------------
Message: 3
Date: Fri, 3 Feb 2017 08:29:02 -0600
From: "David M. Lloyd" <david.lloyd at redhat.com>
To: jigsaw-dev at openjdk.java.net
Subject: Re: Automatic module names
Message-ID: <54002ec6-be4d-ec33-6e60-8b5e1fb91a33 at redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
I think one option we should consider is to perhaps disable automatic
modules for 9 and revisit the idea for 10, as it's late in the day and
still clearly not settled.
On 02/03/2017 05:44 AM, Robert Scholte wrote:
> Hi Nicolai,
>
> let's consider that my project depends on the following dependencies:
> com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed.
>
> I somehow want to have them both as requirements:
> module M.N {
> requires static library; // com.foo.bar:library
> requires library; // com.acme:library
> }
>
> How can I define that the 'requires static library' should be mapped to
> com.foo.bar:library:1.0 on the modulepath, while 'requires library'
> should be mapped to com.acme:library:2.3.1
>
> One ugly solution would be:
> requires static library containing com.foo.bar.baz.SomeClass;
> requires library containing acme.AnotherClass;
>
> We should really wonder if ease-of-transition is worth the minefield
> we're creating with the introduction of automodules. IMHO all options
> we're trying to add to keep automodules will only over-complicate
> things, not even being sure if all edges are covered.
>
> thanks,
> Robert
>
> On Thu, 02 Feb 2017 12:28:13 +0100, Nicolai Parlog <nipa at codefx.org>
wrote:
>
>> Hi everyone,
>>
>> after thinking about this a little longer, I came to the conclusion that
>> compile-time/launch-time aliasing might be the only way out of this (at
>> least the only I could come up with) that keeps automatic modules alive
>> and does not introduce a conceptual dependency on Maven.
>>
>> The idea:
>>
>> A command line option, let's say `--alias-modules A=X`, maps module name
>> A to module name X. Every dependency on either A or X will be resolved
>> to X, implying that there must a module X in the universe of observable
>> modules. There can be several aliases for the same module
>> (`--alias-modules A=X,B=X`; X needs to be observable) and they can be
>> chained (`--alias-modules A=X,X=Y`; Y needs to be observable)
>>
>> Aliasing would of course have to be applied to qualified exports, opens,
>> and similar mechanisms as well.
>>
>> It might be worth adding the rule that no observable module must have an
>> aliased name. So for `--alias-modules A=X` there must be no observable
>> module A. This prevents ambiguity and would effectively prevent aliasing
>> platform modules. That might be a good thing because it looks like
>> aliasing and upgrading modules has quite some overlap (or is even
>> identical?)
>>
>> Unfortunately I could not come up with a way to limit aliasing to
>> automatic module names (in case that were desirable) without somehow
>> marking dependencies on automatic modules, likely in the module
>> declaration. If changing module declaration syntax is still on the
>> table, it could be changed so that dependencies on automatic modules
>> must be phrased as something like `requires automatic`.
>>
>> The obvious semantics would be that only such requires clauses can be
>> fulfilled with automatic modules and that only such dependencies could
>> be aliased (this might make it prudent to phrase the aliasing option
>> accordingly, e.g. `--alias-automatic-modules`).
>>
>> This could also be used to help developers in keeping their module
>> declarations clean: The compiler could to emit a warning if a `requires
>> automatic` clause is fulfilled by a regular module.
>>
>> I would love to hear some thoughts on this idea, even if it considered
>> to be stupid, impractical,etc. :)
>>
>> so long ... Nicolai
>>
>>
>>
>> On 27.01.2017 15:11, Stephen Colebourne wrote:
>>> Back in October, I raised the issue of modules names generally and for
>>> automatic modules specifically [1]. The short thread came to no
>>> conclusion, but recent threads have again raised similar problems. The
>>> problem is that automatic modules have magical name creation from a
>>> filename, which is brittle and unlike anything else in Java.
>>>
>>> I also recently looked at the Joda-Convert and Joda-Beans libraries,
>>> to see if I could add module-info in preparation for Java 9. I quickly
>>> backed away, again because of the same issue. Put simply, I am
>>> unwilling to write a module-info file that refers to a dependency that
>>> is not yet a module. And I have to advise all open source projects to
>>> do the same. Given this, there can be no simple migration to the JPMS
>>> for open source projects. Each open source project must wait for all
>>> its dependencies to migrate to JPMS (by adding a module-info and
>>> publishing to Maven Central).
>>>
>>> The issue is clear. If I write this:
>>>
>>> module org.joda.convert {
>>> requires guava;
>>> }
>>>
>>> where guava is an automatic module, I am locking in the name of the
>>> guava dependency, something that I do not control. The name "guava" is
>>> just a guess. The guava authors might choose "com.google.guava" or
>>> something else entirely.
>>>
>>> In a closed system of modules, ie. a private application, automatic
>>> modules are fine, because the requires clause can be changed if it
>>> turns out the guess was wrong. But once published as an open source
>>> project to Maven Central or elsewhere, the guess cannot be fixed if it
>>> is wrong (without releasing a new version of the library, which is not
>>> an acceptable solution).
>>>
>>> I also strongly believe that module names cannot be flat and
>>> unstructured, such as "joda-convert" or "guava". They must have
>>> structure, such as the domain name or a Maven-style group name
>>> "org.joda.convert" or "org.joda:joda-convert". The potential for
>>> clashes has been shown by the Maven team [2].
>>>
>>> Some brainstormed possible changes:
>>>
>>> - Remove the automatic module concept altogether
>>>
>>> - Define a clear mapping from Maven Central co-ordinates to module
>>> name that includes the group, artifact and classifier
>>>
>>> - Provide a text file to JPMS that allows incorrect module names to be
>>> mapped to the correct name
>>>
>>> - Publicly advise against using automatic modules for open source
>>> projects
>>>
>>> - Change rules of Maven Central to prevent modular jars being added
>>> that depend on an automatic module
>>>
>>> - Allow requires clauses to have aliases - requires org.guava.guava
>>> OR guava.
>>>
>>> - Allow modules to have aliases - module org.guava.guava AKA guava
>>>
>>>
>>> Given that applications can depend on libraries that haven't been
>>> released in years, this has the potential to be a critical problem for
>>> the ecosystem. My preference remains to define a clear mapping from
>>> the widely adopted Maven Central naming strategy to JPMS modules.
>>> Ideally, this would be a formal group concept in the JPMS, something
>>> that I believe is sorely lacking.
>>>
>>> Stephen
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-
October/009631.html
>>>
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/jpms-spec-observers/
2017-January/000707.html
>>>
>>>
--
- DML
------------------------------
Message: 4
Date: Fri, 3 Feb 2017 14:43:41 +0000
From: Andrew Dinn <adinn at redhat.com>
To: "David M. Lloyd" <david.lloyd at redhat.com>,
jigsaw-dev at openjdk.java.net
Subject: Re: Automatic module names
Message-ID: <5ba1ec95-4382-d38f-1e0f-0e5509179c39 at redhat.com>
Content-Type: text/plain; charset=utf-8
On 03/02/17 14:29, David M. Lloyd wrote:
> I think one option we should consider is to perhaps disable automatic
> modules for 9 and revisit the idea for 10, as it's late in the day and
> still clearly not settled.
I don't think this is thinking about the trade-off correctly.
Automatic modules may not work for some (or maybe many) of the more
complicated cases but those failures can be addressed over time by
adding a module.xml to update releases of jars.
Automatic modules definitely does work for straightforward cases to
provide an easy way of deploying jars you don't own/can't rewrite as
modules.
Much as I admit that there are going to be lots of cases where it will
fail I think those where it just works will still be a large subset. So,
automatic modules will definitely be a big help to a lot of users who
want to get started with Jigsaw.
And, well, maybe I need to say this -- yes, an easy start is a /big/
priority.
That's merely 2 cents, gratis. Your mileage may vary, particularly when
it fails for your app. But I don't the mere possibility of the latter as
a reason to poop on someone (everyone?) else's parade.
regards,
Andrew Dinn
-----------
------------------------------
Message: 5
Date: Fri, 3 Feb 2017 15:40:43 +0000
From: Alan Bateman <Alan.Bateman at oracle.com>
To: Robert Scholte <rfscholte at apache.org>, jigsaw-dev at openjdk.java.net
Subject: Re: Automatic module names
Message-ID: <617664d5-8ea6-1be8-7790-8d7ecd669e96 at oracle.com>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
On 03/02/2017 11:44, Robert Scholte wrote:
> Hi Nicolai,
>
> let's consider that my project depends on the following dependencies:
> com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed.
>
> I somehow want to have them both as requirements:
> module M.N {
> requires static library; // com.foo.bar:library
> requires library; // com.acme:library
> }
>
> How can I define that the 'requires static library' should be mapped
> to com.foo.bar:library:1.0 on the modulepath, while 'requires library'
> should be mapped to com.acme:library:2.3.1
>
> One ugly solution would be:
> requires static library containing com.foo.bar.baz.SomeClass;
> requires library containing acme.AnotherClass;
>
> We should really wonder if ease-of-transition is worth the minefield
> we're creating with the introduction of automodules. IMHO all options
> we're trying to add to keep automodules will only over-complicate
> things, not even being sure if all edges are covered.
I think automatic modules are critical to migration, otherwise things
move at the pace of the slowest project (which might be 0km/h in case of
unmaintained projects). A lot of the discussion here has been on the
naming but automatic modules but the other important benefit of
automatic modules is that they support bridging to the class path.
As regards the example naming clash then these two projects might
already get complaints over their poor choice of artifacts, esp. when
artifacts for both projects are in same directory (say where someone
distributes with all JAR files in a `lib` directory).
-Alan
------------------------------
Message: 6
Date: Fri, 3 Feb 2017 16:34:11 +0000
From: Stephen Colebourne <scolebourne at joda.org>
To: jigsaw-dev <jigsaw-dev at openjdk.java.net>
Subject: Re: Automatic module names - "requires package" proposal
Message-ID:
<CACzrW9AtL+Ck0-MWSLjXcCOB6J=zGu35ZLUyCjvHJCWuvHYKfA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On 3 February 2017 at 15:40, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> I think automatic modules are critical to migration, otherwise things move
> at the pace of the slowest project (which might be 0km/h in case of
> unmaintained projects). A lot of the discussion here has been on the
naming
> but automatic modules but the other important benefit of automatic modules
> is that they support bridging to the class path.
>
> As regards the example naming clash then these two projects might already
> get complaints over their poor choice of artifacts, esp. when artifacts
for
> both projects are in same directory (say where someone distributes with
all
> JAR files in a `lib` directory).
We can't close our eyes to this problem. There can be naming clashes
as above, naming problems due to having to guess a project's choice of
a module name. We need to take the guesswork out, and have something
based on Java compilation elements.
As such, I'd like to propose an alternative based on packages that
could still be feasible in the time available:
1) Have two types of `requires` clause - one for modules and one for
packages
2) When requiring a package, that package must be available, either on
the classpath or in a module
3) When requiring a package, the package must not be found in a module
that is explicitly referenced
4) Fully modularized applications do not have `requires package` -
this is a migration feature like `open modules`
module com.org.a {
// dependency on a module (modular jar)
requires module com.org.b;
requires module com.org.c;
// dependency on packages (modular jar or classpath)
requires package com.org.d;
requires package com.org.d.x;
requires package com.org.d.y;
}
In the example above, the three explicitly specified packages must not
be found in module `com.org.b` or `com.org.c` (rule #3). They must
instead be found in a jar on the classpath (each package must be found
only in one jar), or in a future module (which could have any name,
not just `com.org.d` or `d`).
The `requires package` provides the "bridge" to the classpath and
older jars that is desired, without the mess of automatic modules.
Note that there would be no automatic modules as currently planned in
this proposal.
(FWIW, in the implementation, I'd imagine that each required package
would be created as a separate module, using the same openess/security
design as automatic modules today)
Stephen
End of jigsaw-dev Digest, Vol 87, Issue 6
*****************************************
More information about the jigsaw-dev
mailing list