I totally agree. This feels like a royally bad idea that is totally counter to the idea for slim runtime and fast startup times. I would much rather have some additional info somewhere in the archive that documents used bytecode, supported runtime and things like that.
On the Maven side it would be good to have some standard way to include this information in the coordinates maybe so that things could be validated even before downloading the archive, opening it up and parsing it. Ideally it would be a better solution than the classifier based approach used in the past.. Maybe this is a hot candidate for the consumer pom work.. manfred Gary Gregory wrote on 19.03.2015 15:43: > 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 >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
