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 r
On 04/15/2015 02:44 PM, Paul Sandoz wrote:
Hi Remi,
On Apr 15, 2015, at 1:58 PM, Remi Forax 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 aspe
On 04/15/2015 02:59 PM, Paul Sandoz wrote:
On Apr 15, 2015, at 2:03 PM, Remi Forax 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, int
On Apr 15, 2015, at 2:03 PM, Remi Forax 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
>> perhaps mor
Hi Remi,
On Apr 15, 2015, at 1:58 PM, Remi Forax 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.
>
> You're asking Jav
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:
http://markmail.org/thread/v5ywgdpuprntrvfu#query:+page:1+mid:v5ywgdpuprntrv
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 of
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 th
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 against
Sorry for the late reply, getting through email backlogs...
On Mar 1, 2015, at 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 wrote:
>>> I really don't think this tooling support will provide sufficient
>>> enticement
On 1 March 2015 at 23:37, Remi Forax 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 to create the
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 Ja
Hi Moh,
On Feb 27, 2015, at 7:23 PM, "Rezaei, Mohammad A."
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 deployed to maven
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 s
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
down
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 p
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 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.
On 02/27/2015 06:16 PM, Paul Sandoz wrote:
> On Feb 27, 2015, at 4:47 PM, Florian Weimer 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
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 sufficie
2015 12:16 PM
>Cc: core-libs-dev@openjdk.java.net
>Subject: Re: JEP 238: Multi-Version JAR Files
>
>On Feb 27, 2015, at 4:47 PM, Florian Weimer wrote:
>> I really don't think this tooling support will provide sufficient
>> enticement to developers to maintain separate 7/8
On Feb 27, 2015, at 4:47 PM, Florian Weimer 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?
>
What if al
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 (no
On Feb 27, 2015, at 2:27 PM, 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 especi
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
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 hearing
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 9:00 AM, Paul Sandoz wrote:
>
> On Feb 26, 2015, at 5:02 PM, Paul Sandoz 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 dev
On Feb 26, 2015, at 5:02 PM, Paul Sandoz 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 this time...
On Feb 26, 2015, at 5:02 PM, Paul Sandoz 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:
>
> multiversion-jar $ java -ve
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 (buil
On 25/02/2015 18:03, Paul Sandoz wrote:
On Feb 25, 2015, at 6:45 PM, Stephen Colebourne wrote:
On 25 February 2015 at 13:30, Paul Sandoz 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 th
On 02/25/2015 11:41 AM, Paul Sandoz wrote:
On Feb 25, 2015, at 5:27 PM, Brian Goetz 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 o
On Feb 25, 2015, at 6:45 PM, Stephen Colebourne wrote:
> On 25 February 2015 at 13:30, Paul Sandoz 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 availa
On Feb 25, 2015, at 5:27 PM, Brian Goetz 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 example, but
On 25 February 2015 at 13:30, Paul Sandoz 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 path.
To be honest, b
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 w
Hi Peter,
On Feb 14, 2015, at 8:54 PM, Peter Levart 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
>>
>
HI Peter,
On Feb 14, 2015, at 3:56 PM, Peter Levart 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 structure:
>
> my.pr
On Feb 12, 2015, at 11:59 PM, Stephen Colebourne 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
> for example, but
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
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 d
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 d
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 cl
43 matches
Mail list logo
