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
<[email protected]>:
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 <[email protected]>
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
