maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
Date Thu, 19 Mar 2015 22:43:12 GMT
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.


On Thu, Mar 19, 2015 at 3:38 PM, Robert Scholte <>

> 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]
>  [1]
> 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:
> For additional commands, e-mail:

E-Mail: |
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition <>
Spring Batch in Action <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message