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
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.
2. Provide a mechanism to "glue" the generated module-info files to the
original non-modular
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
Hi Paul,
> On 31 Aug 2016, at 20:25, Paul Benedict wrote:
>
> Neil, but doesn't the prohibition of duplicate packages continue to rear
> its head?
I’m sorry I lost track of the context of this question! If you’re asking
whether OSGi is prohibited from loading duplicate packages on Java 9, the
,
> 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
Alex,
You wrote:
> I see no reason why a
> future project that wanted to introduce first-class versions couldn't do
> it on top of JDK 9.
When I asked you to clarify how it could do so you responded with a
non-answer. This doesn't inspire much confidence.
As far as I can tell, the current synt
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
Alex,
Thank you for the clarification.
I am a bit confused by your assertion... If you wanted to introduce
first-class versions in JDK 10, how would you do so (without breaking
backwards compatibility) in light of this format?
module com.foo.bar {
*requires* org.baz.qux;
}
Gili
On 2016
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
Alex,
I get this point but if "requires" does not take a version number today
then the Java launcher can never add this functionality in the future.
On the flip side, if you take a version string today and decide to drop
it tomorrow ("this value is ignored in Java 12 and higher") there is
mini
Alex,
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 containers, but this is
simply not th
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
I don't disagree.
By requiring developers to provide constant version numbers we kill two
birds with one stone:
* We solve part of the "classpath hell" problem out-of-the-box.
* We future-proof the specification so version handling can be
extended in the future.
If "requires" does not t
In the JDK 8 java launcher, classpath hell is having two [incompatible]
versions of the "same" JAR on the classpath and getting types from both
of them.
In the JDK 9 java launcher, we avoid modulepath hell -- two
[incompatible] versions of the "same" module on the modulepath -- by
uniquifying
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
There are two dimensions to the version range issue: build
reproducibility and future-proofing.
In the former category, single versions are generally used for build
because that ensures that the build will not change over time as new
versions of things become available. In other words, I buil
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
Neil, but doesn't the prohibition of duplicate packages continue to rear
its head?
Cheers,
Paul
On Wed, Aug 31, 2016 at 2:21 PM, cowwoc wrote:
> Well, this is unfortunate. As I stated earlier, I fail to see how
> depending on constant version numbers (not version ranges) fall under
> the scope
Well, this is unfortunate. As I stated earlier, I fail to see how
depending on constant version numbers (not version ranges) fall under
the scope of "version selection". Was this case considered/discussed in
depth?
Not everyone is sold on version ranges (e.g. the vast majority of Maven
artifac
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
38 matches
Mail list logo
