On 02/09/2016 10:35, Richard Opalka wrote:
:
Will Java support classpath forever or there are plans to remove it?
Asking because if classpath would be removed some time in the future
such compromise (automatic modules) is just short term win affecting
many key design decisions.
I'm not aware of
On 09/02/2016 10:27 AM, Alan Bateman wrote:
On 01/09/2016 21:04, cowwoc wrote:
Another possibility (not saying it's better, just putting it out there)
is to do the following:
1. Provide a tool like "javah" that would generate module-info.java
for
non-modularized JAR files.
Look at `
On 01/09/2016 21:04, cowwoc wrote:
Another possibility (not saying it's better, just putting it out there)
is to do the following:
1. Provide a tool like "javah" that would generate module-info.java for
non-modularized JAR files.
Look at `jdeps --gen-module-info ..`. It's a starting po
Reformulating the idea to make it more clear:
On 09/01/2016 06:34 PM, Richard Opalka wrote:
On 09/01/2016 03:59 PM, Alan Bateman wrote:
The issue is of course that there is lot more in picture, esp. when
you have the unnamed module (= class path) reading all modules, also
automatic modules tha
les
> would disappear.
>
> Richard
>
>
> ----
> If you reply to this email, your message will be added to the
> discussion below:
> http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-o
On 09/01/2016 06:58 PM, Alan Bateman wrote:
On 01/09/2016 17:34, Richard Opalka wrote:
Further I can't see the real benefit of automatic modules (they read
UNNAMED module(s) and all other explicit modules).
I am aware of two real world usecases it might solve:
1) to workaround licensing issues
On 01/09/2016 15:35, David M. Lloyd wrote:
Yeah having the class path remain on the legacy application class
loader is demonstrably better for interop. But new modules? Does
that make sense?
Yes, specifically automatic modules where a JAR file is moved from the
class path to module path wi
On 01/09/2016 17:34, Richard Opalka wrote:
- [C] UNNAMED classpath module shouldn't see non-platform explicit
modules by default
(users might use -XaddExports to export them explicitly with risk
for split-package issue and other issues)
That is how it works, except you use --add-modules t
On 09/01/2016 03:59 PM, Alan Bateman wrote:
The issue is of course that there is lot more in picture, esp. when
you have the unnamed module (= class path) reading all modules, also
automatic modules that bridge to the class path (and so read the
unnamed module). Then add upgradable modules into
ning a private package org.example.util. The
>>>>> following exception resulted:
>>>>> java.lang.reflect.LayerInstantiationException: Package org.example.util
>>>>> in both module a and module b.
>>>>>
>>>>> Again this co
a and module b.
>>>>
>>>> Again this could be “solved” by using custom ClassLoaders or a
>>>> ClassLoader-based module system like OSGi on Java 9.
>>>>
>>>> Neil
>>>>
>>>>
>>>>
>>>>> On 31 A
On 09/01/2016 08:59 AM, Alan Bateman wrote:
On 01/09/2016 13:29, David M. Lloyd wrote:
It seems like there is no good reason why the application modules
aren't loaded with classloader-per-module now. The platform stuff
could all be in one, but the application stuff? Problems like this
are goi
gt;>> On 31 Aug 2016, at 20:28, Remi Forax <[hidden email]
> > wrote:
> >>>
> >>> The other solution is to statically link the right version of
> slf4j inside guava and jsoup.
> >>> A tool like jarjar can be updated to merge two modular jars (merge
On 01/09/2016 13:29, David M. Lloyd wrote:
It seems like there is no good reason why the application modules
aren't loaded with classloader-per-module now. The platform stuff
could all be in one, but the application stuff? Problems like this
are going to come up a lot otherwise; let's consid
r jars (merge two
module-info).
cheers,
Rémi
- Mail original -
De: "Neil Bartlett"
À: cow...@bbs.darktech.org, "Alex Buckley"
Cc: "ZML-OpenJDK-Jigsaw-Developers"
Envoyé: Mercredi 31 Août 2016 20:54:44
Objet: Re: Multiple versions of a non-exported dependency
be updated to merge two modular jars (merge two
>>> module-info).
>>>
>>> cheers,
>>> Rémi
>>>
>>> ----- Mail original -
>>>> De: "Neil Bartlett"
>>>> À: cow...@bbs.darktech.org, "Alex Buckley&
- Mail original -
De: "Neil Bartlett"
À: cow...@bbs.darktech.org, "Alex Buckley"
Cc: "ZML-OpenJDK-Jigsaw-Developers"
Envoyé: Mercredi 31 Août 2016 20:54:44
Objet: Re: Multiple versions of a non-exported dependency
Gili,
As Alex points out: your use-case
On 01/09/2016 08:28, Neil Bartlett wrote:
:
In contrast, Jigsaw/JPMS implements isolation using access control rather than
ClassLoader visibility. All modules on the modulepath are loaded into the same
ClassLoader, and a single ClassLoader can have at most one definition of each
class. The im
slf4j_v1.jar and slf4j_v2.jar on the
>>> modulepath, and Guava requires slf4j_v1 and JSoup requires slf4j_v2,
>>> then launching 'java -m HelloWorld' will fail. The boot layer will
>>> refuse to map the "same" packages from different slf4j_v* modul
,
> Rémi
>
> - Mail original -
>> De: "Neil Bartlett"
>> À: cow...@bbs.darktech.org, "Alex Buckley"
>> Cc: "ZML-OpenJDK-Jigsaw-Developers"
>> Envoyé: Mercredi 31 Août 2016 20:54:44
>> Objet: Re: Multiple versions of a non
--------
> If you reply to this email, your message will be added to the
> discussion below:
> http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713379.html
>
>
> To unsubscribe from Mul
rsions.
>
> https://xkcd.com/927/
>
> Rémi
>
> - Mail original -
> > De: "Alex Buckley" <[hidden email]
> >
> > À: [hidden email]
> > Envoyé: Mercredi 31 Août 2016 22:07:59
> > Objet: Re: Multiple versions of a non-exported dependenc
---
> De: "Alex Buckley"
> À: jigsaw-dev@openjdk.java.net
> Envoyé: Mercredi 31 Août 2016 22:07:59
> Objet: Re: Multiple versions of a non-exported dependency
> On 8/31/2016 12:51 PM, cowwoc wrote:
>> I agree that the situation is better, but not by much. Developers
&
This has been a good conversation but I'm unwilling to enter into
unbounded discussion of hypothetical future features. Here are some
practical things you can try with JDK 9 right now:
- Have you run your JDK 8 application on a JDK 9 EA build?
- Have you jlinked an image consisting of a handful
---
> If you reply to this email, your message will be added to the
> discussion below:
> http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713377.html
>
>
> To unsubscribe from Multiple versions of a non-exported dependency,
On 8/31/2016 12:51 PM, cowwoc wrote:
I agree that the situation is better, but not by much. Developers
routinely run across transitive dependencies that are incompatible with
each other. You seem to be under the impression that this a rare
occurrence or only occurs in the context of web container
all "the 'java' launcher".
>
>
> ----
> If you reply to this email, your message will be added to the
> discussion below:
> http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-e
e modulepath, then the first one to be found will
> >> dominate, and that's what will be resolved for both Guava and JSoup.
> >>>
> >>> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the
> >> modulepath, and Guava requires slf4j_v1 and JSoup requires slf4j_v2,
> >> then launching 'java -m He
On 8/31/2016 12:39 PM, cowwoc wrote:
I don't even care if you keep the current restrictions in place (allow
only one version per layer)
There is no such restriction in the Java Platform Module System --
please look at java.lang.reflect.Layer. The restriction to a single
version of each module
ARs slf4j_v1.jar and slf4j_v2.jar on the
> >> modulepath, and Guava requires slf4j_v1 and JSoup requires slf4j_v2,
> >> then launching 'java -m HelloWorld' will fail. The boot layer will
> >> refuse to map the "same" packages from different slf4j_v*
resentations. The use case just
isn't supported "out of the box" by the 'java' launcher for JARs on
the modulepath.
Alex
----
If you reply to this email, your message will be added to the
discus
ot;Alex Buckley" <[hidden email]
> >
> > Cc: "ZML-OpenJDK-Jigsaw-Developers" <[hidden email]
> >
> > Envoyé: Mercredi 31 Août 2016 20:54:44
> > Objet: Re: Multiple versions of a non-exported dependency
>
> > Gili,
> >
> > As Al
a' launcher for JARs on
the modulepath.
Alex
----------------
If you reply to this email, your message will be added to the
discussion below:
http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713
t;Alex Buckley"
> Cc: "ZML-OpenJDK-Jigsaw-Developers"
> Envoyé: Mercredi 31 Août 2016 20:54:44
> Objet: Re: Multiple versions of a non-exported dependency
> Gili,
>
> As Alex points out: your use-case can be supported in Java 9 but only with the
> addition of custo
ot;same" packages from different slf4j_v* modules to
> > the application class loader.
> > >
> > > The use case _is_ supported on JDK 9 for modular JARs loaded into
> > custom loaders of custom layers. That is, the Java Platform Module
> > System is
JDK 9 for modular JARs loaded into
> custom loaders of custom layers. That is, the Java Platform Module
> System is perfectly capable of supporting the use case -- please see
> any of my "Jigsaw: Under The Hood" presentations. The use case just
> isn't supported "ou
Gili,
As Alex points out: your use-case can be supported in Java 9 but only with the
addition of custom ClassLoaders, or by using an existing ClassLoader-based
module system such as OSGi.
The same is also true of Java 8, and Java 7, etc.
Regards,
Neil
> On 31 Aug 2016, at 19:29, Alex Buckley
On 8/31/2016 10:56 AM, cowwoc wrote:
I recently became aware of the fact that the Jigsaw specification declared
"version-selection" as a non-goal. While I understand how we ended up here,
I am hoping that you were able to support the following (very common)
use-case:
* Module "HelloWorld" depend
ining that fixed version, and pass that to
the JDK at build time. Would that not work?
If "requires" no longer takes a version number, I fear that you will never
be able to add versioning support in the future...
Thanks,
Gili
--
View this message in context:
http://jigsaw-dev.1059479
39 matches
Mail list logo
