Also have a look at
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
it looks more complete and has some additional usecases
Robert
Op Fri, 20 Mar 2015 17:24:08 +0100 schreef Jason van Zyl <ja...@takari.io>:
I'm just reading http://openjdk.java.net/jeps/238 and I encourage
everyone else to as well. Mark talked about this at EclipseCon and I'm
not sure what this buys you. I can see the goals in the JEP but it isn't
really clear about the problem this JEP is trying to solve. I will pop
on the mailing list and see if I can get an answer. But immediately I
see complexity added because the compiler, archiving mechanisms and
signing mechanism all need to be altered. Maybe it is a benefit, I'm not
really sure yet but at first blush I can't see it myself.
On Mar 20, 2015, at 12:14 PM, Robert Scholte <rfscho...@apache.org>
wrote:
I agree on the "feels wrong".
I don't think it will become that much heavier, assuming most of the
time you don't need multi-version classes in an archive. Now you know
for sure that a number of classes won't be used, but in general you
always get overhead from classes in jars which aren't used. Every time
I use maven-shade-plugin + minimizeJar=true the results are impressive.
I'm more worried about the complexity and combination with what we gain
with it.
thanks,
Robert
Op Thu, 19 Mar 2015 23:43:12 +0100 schreef Gary Gregory
<garydgreg...@gmail.com>:
The level of granularity feels wrong.
This sounds like it would make jar "heavier", potentially a lot
heavier.
Another angle would be to manage versions 1-1 with jars, one jar for
java
7, one for java 8, and so on. With >1 version in one jar, I am FORCED
to
download versions of class files I'll never use. That seems like a bad
idea
baked in.
Gary
On Thu, Mar 19, 2015 at 3:38 PM, Robert Scholte <rfscho...@apache.org>
wrote:
Hi,
we've been asked to give our opinion on the JEP 238: Multi-Version JAR
Files
Here's a quote from Rory O'Donnels e-mail:
---
It's goal is to extend the JAR file format to allow multiple, JDK
release-specific versions of class
files to coexist in a single file. An additional goal is to backport
the
run-time changes to
JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a
detailed discussion,
please see the corresponding thread on the core-libs-dev mailing
list. [1]
Please keep in mind that a JEP in the Candidate state is merely an
idea
worthy of consideration
by JDK Release Projects and related efforts; there is no commitment
that
it will be delivered in
any particular release.
Comments, questions, and suggestions are welcome on the corelibs-dev
mailing list. (If you
haven’t already subscribed to that list then please do so first,
otherwise your message will be
discarded as spam.)
[0] http://openjdk.java.net/jeps/238
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-
February/031461.html
---
IIUC the original request was to have different version of the same
class
within the same artifact. On the mailinglist I noticed a more
interesting
idea: you need a mechanism to map Classes, Methods or Fields from one
version to the other.
From a Maven perspective I don't see that much issues with the
original
idea. You should already be able to do it right now with a lot of
execution-blocks.
However, I don't see how users would maintain different version of the
same class (within an IDE).
To me this all looks quite complex for rare cases.
If you really want multiple JDK versions of the same artifact, I would
probably split them into classified artifacts.
Any other comments?
thanks,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
I never make the mistake of arguing with people for whose opinions I
have no respect.
-- Edward Gibbon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
