I think a use-case that supports the JEP would be the Spring Framework. They are typically supporting a couple versions of Java at once *in one release* and they have some utility code to access the latest features *if* they are available in the running JRE. However, to do that, they use class loading tests and testing for the existence of methods via reflection. Here, I could say, the JEP makes sense. Rather than doing reflection tricks, you could compile the < 1% of your code base appropriately for the different Java versions you want to support. On the flip side, 99% of the code runs on any Java version.
Another such example could be the use of Unsafe in older Java versions and newer API replacements in later versions. Again, the use of this JEP should be limited to a few utility classes in your code. This kind of *extreme* proportionality is where I can support the JEP. Paul Cheers, Paul On Fri, Mar 20, 2015 at 11:31 AM, Robert Scholte <rfscho...@apache.org> wrote: > 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 > >
