On 04/15/2015 01:04 PM, Paul Sandoz wrote:
Hi Markus,
Sorry for the late reply i have been away for the last 3 weeks.
You and your colleagues might be interested in discussion of JEP 238 on
org.apache.maven.dev:
On Apr 15, 2015, at 2:03 PM, Remi Forax fo...@univ-mlv.fr wrote:
Of course we cannot feasibly backport every new API in N to N-1, N-2 etc. In
selective cases that might be possible, but for the core of the JDK it's
like pulling on a string of public dependencies, internal dependencies and
Hi Remi,
On Apr 15, 2015, at 1:58 PM, Remi Forax fo...@univ-mlv.fr wrote:
Hi Paul,
I think you're seriously underestimate the cost of this JEP.
That is why we are asking for feedback :-) I want to understand the impact and
get some concrete reasons why certain aspects are difficult.
Hi Paul,
I think you're seriously underestimate the cost of this JEP.
You're asking Java devs to:
- be able to maintain several codes with different source level
compatibility in the same code tree.
- add a level of indirection in all tools that crawle/compile Java
source code
- add a level
Note that one possible feature of JDK 9 is a -platform N option to javac
which would allow compiling against older versions of the platform
libraries:
JEP draft: Compile for Specific Platform Version
http://openjdk.java.net/jeps/8058150
This feature would address some of the concerns
On 04/15/2015 02:59 PM, Paul Sandoz wrote:
On Apr 15, 2015, at 2:03 PM, Remi Forax fo...@univ-mlv.fr wrote:
Of course we cannot feasibly backport every new API in N to N-1, N-2 etc. In
selective cases that might be possible, but for the core of the JDK it's like
pulling on a string of public
On 04/15/2015 02:44 PM, Paul Sandoz wrote:
Hi Remi,
On Apr 15, 2015, at 1:58 PM, Remi Forax fo...@univ-mlv.fr wrote:
Hi Paul,
I think you're seriously underestimate the cost of this JEP.
That is why we are asking for feedback :-) I want to understand the impact and
get some concrete
Hi Markus,
Sorry for the late reply i have been away for the last 3 weeks.
You and your colleagues might be interested in discussion of JEP 238 on
org.apache.maven.dev:
http://markmail.org/thread/v5ywgdpuprntrvfu#query:+page:1+mid:v5ywgdpuprntrvfu+state:results
especially when it gets to
I've discussed this with the Eclipse JDT team. We're very skeptic and we
think that JEP 238 goes into a wrong direction. Eclipse JDT does not
intend to add special support for it.
Building such MVJARs will be quite complicated, since it requires having
separate classpaths and compiling
Sorry for the late reply, getting through email backlogs...
On Mar 1, 2015, at 11:41 AM, Florian Weimer fwei...@redhat.com wrote:
On 02/27/2015 06:16 PM, Paul Sandoz wrote:
On Feb 27, 2015, at 4:47 PM, Florian Weimer fwei...@redhat.com wrote:
I really don't think this tooling support will
On 1 March 2015 at 23:37, Remi Forax fo...@univ-mlv.fr wrote:
You only maintain one module which depend on the latest version.
When you ship the module let say as a jar, you also ship the way to
downgrade it as an executable code.
At install time, when all the modules are known, before trying
Hi Moh,
On Feb 27, 2015, at 7:23 PM, Rezaei, Mohammad A. mohammad.rez...@gs.com
wrote:
Why do you expect the new classes in the JDK not to be part of the API?
An MVJAR is one unit of release. Should it have two or more public APIs? if so
what is it's version and set of dependencies? Can it be
On 02/25/2015 05:27 PM, Brian Goetz wrote:
On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
I would expect IDEs to have some considerable work to do.
Agree on the work part, but I doubt it is considerable.
For creating MV JARs, the 'jar' tool does all the heavy lifting.
For running Java
On 03/02/2015 12:37 AM, Remi Forax wrote:
On 03/01/2015 07:08 PM, Peter Levart wrote:
Hi Peter,
You can see the whole thing in the opposite way which I think is less
disruptive in term of tooling.
You only maintain one module which depend on the latest version.
When you ship the module let
On 03/01/2015 07:08 PM, Peter Levart wrote:
Hi Peter,
You can see the whole thing in the opposite way which I think is less
disruptive in term of tooling.
You only maintain one module which depend on the latest version.
When you ship the module let say as a jar, you also ship the way to
On 03/01/2015 11:41 AM, Florian Weimer wrote:
On 02/27/2015 06:16 PM, Paul Sandoz wrote:
On Feb 27, 2015, at 4:47 PM, Florian Weimer fwei...@redhat.com wrote:
I really don't think this tooling support will provide sufficient
enticement to developers to maintain separate 7/8/9 source branches
On 02/27/2015 06:16 PM, Paul Sandoz wrote:
On Feb 27, 2015, at 4:47 PM, Florian Weimer fwei...@redhat.com wrote:
I really don't think this tooling support will provide sufficient
enticement to developers to maintain separate 7/8/9 source branches of
their libraries. Isn't that the main
On 03/01/2015 12:53 PM, Remi Forax wrote:
Currently, there are two ways to solve the Base64 issue:
- by loading at runtime either the class that use java.util.Base64 or
the class sun.misc.BASE64Decoder and use it through an interface
And this, I think, is also the cleanest way to approach a
On 02/27/2015 07:27 AM, Florian Weimer wrote:
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
We are especially interesting in
On Feb 27, 2015, at 4:47 PM, Florian Weimer fwei...@redhat.com wrote:
I really don't think this tooling support will provide sufficient
enticement to developers to maintain separate 7/8/9 source branches of
their libraries. Isn't that the main obstacle, and not the way the bits
are delivered?
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
We are especially interesting in hearing feedback from library developers,
On Feb 27, 2015, at 2:27 PM, Florian Weimer fwei...@redhat.com wrote:
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
We are
On 27/02/2015 13:27, Florian Weimer wrote:
:
I'm wondering how you propose to build such JAR files. Do you think
library developers will maintain two separate branches, compile one with
JDK 8, the other one with JDK 9, and then use some (not yet existing?)
tool to merge the output into a single
Le 27/02/15 16:47, Florian Weimer a écrit :
Maybe I misunderstood the multi-version JAR files proposal, but I
thought that the assumption there is that there are actual *source*
files which use newer features of the platform.
I really don't think this tooling support will provide sufficient
@openjdk.java.net
Subject: Re: JEP 238: Multi-Version JAR Files
On Feb 27, 2015, at 4:47 PM, Florian Weimer fwei...@redhat.com wrote:
I really don't think this tooling support will provide sufficient
enticement to developers to maintain separate 7/8/9 source branches of
their libraries. Isn't that the main
On 02/27/2015 03:20 PM, Alan Bateman wrote:
On 27/02/2015 13:27, Florian Weimer wrote:
:
I'm wondering how you propose to build such JAR files. Do you think
library developers will maintain two separate branches, compile one with
JDK 8, the other one with JDK 9, and then use some (not yet
On Feb 26, 2015, at 5:02 PM, Paul Sandoz paul.san...@oracle.com wrote:
Hi,
If anyone wants to give this a test drive see stuff in here:
http://cr.openjdk.java.net/~psandoz/multiversion-jar/
produced by Steve (CC'ed) who has done all the development.
Another correction, CC'ing Steve
On Feb 27, 2015, at 9:00 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Feb 26, 2015, at 5:02 PM, Paul Sandoz paul.san...@oracle.com wrote:
Hi,
If anyone wants to give this a test drive see stuff in here:
http://cr.openjdk.java.net/~psandoz/multiversion-jar/
produced by Steve
On Feb 26, 2015, at 5:02 PM, Paul Sandoz paul.san...@oracle.com wrote:
Hi,
If anyone wants to give this a test drive see stuff in here:
http://cr.openjdk.java.net/~psandoz/multiversion-jar/
produced by Steve (CC'ed) who has done all the development.
For example:
Hi,
If anyone wants to give this a test drive see stuff in here:
http://cr.openjdk.java.net/~psandoz/multiversion-jar/
produced by Steve (CC'ed) who has done all the development.
For example:
multiversion-jar $ java -version
java version 1.7.0_72
Java(TM) SE Runtime Environment (build
On Feb 12, 2015, at 11:59 PM, Stephen Colebourne scolebou...@joda.org wrote:
Interesting direction.
Catching up on email after being away last week...
Reading carefully, the goal is actually very limited in scope, by
preventing any public API changes. It doesn't help adoption of JSR-310
HI Peter,
On Feb 14, 2015, at 3:56 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi Paul,
I read through the proposal and couldn't find an explanation of how resources
placed in versioned paths are going to be visible. For example, if the
multi-versioned jar contains the following
Hi Peter,
On Feb 14, 2015, at 8:54 PM, Peter Levart peter.lev...@gmail.com wrote:
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
On Feb 25, 2015, at 6:45 PM, Stephen Colebourne scolebou...@joda.org wrote:
On 25 February 2015 at 13:30, Paul Sandoz paul.san...@oracle.com wrote:
Even in the modular world i will expect class scanning will be used. While
we can now iterate reliably over classes in the image i don't believe
On 25 February 2015 at 13:30, Paul Sandoz paul.san...@oracle.com wrote:
Even in the modular world i will expect class scanning will be used. While we
can now iterate reliably over classes in the image i don't believe that
functionality is made available for classes in modules on the module
On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
Interesting direction.
Reading carefully, the goal is actually very limited in scope, by
preventing any public API changes. It doesn't help adoption of JSR-310
for example, but will be useful for Unsafe, which is clearly a
motivating factor.
I
On Feb 25, 2015, at 5:27 PM, Brian Goetz brian.go...@oracle.com wrote:
On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
Interesting direction.
Reading carefully, the goal is actually very limited in scope, by
preventing any public API changes. It doesn't help adoption of JSR-310
for
On 25/02/2015 18:03, Paul Sandoz wrote:
On Feb 25, 2015, at 6:45 PM, Stephen Colebourne scolebou...@joda.org wrote:
On 25 February 2015 at 13:30, Paul Sandoz paul.san...@oracle.com wrote:
Even in the modular world i will expect class scanning will be used. While we
can now iterate reliably
On 02/25/2015 11:41 AM, Paul Sandoz wrote:
On Feb 25, 2015, at 5:27 PM, Brian Goetz brian.go...@oracle.com wrote:
On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
Interesting direction.
Reading carefully, the goal is actually very limited in scope, by
preventing any public API changes. It
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
We are especially interesting in hearing feedback from library developers,
tool/IDE
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
Hi Paul,
Thinking about this proposal, I can't escape the feeling that the design
New JEP Candidate: http://openjdk.java.net/jeps/238
- Mark
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
We are especially interesting in hearing feedback from library developers,
tool/IDE developers, and anyone doing funky stuff with
Interesting direction.
Reading carefully, the goal is actually very limited in scope, by
preventing any public API changes. It doesn't help adoption of JSR-310
for example, but will be useful for Unsafe, which is clearly a
motivating factor.
I would expect IDEs to have some considerable work to
44 matches
Mail list logo
