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
