JEP 238: Multi-Version JAR Files

Brian Goetz brian.goetz at oracle.com
Wed Feb 25 16:27:14 UTC 2015



On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
> Interesting direction.
>
> Reading carefully, the goal is actually very limited in scope, by
> preventing any public API changes. It doesn't help adoption of JSR-310
> for example, but will be useful for Unsafe, which is clearly a
> motivating factor.
>
> I would expect IDEs to have some considerable work to do.

Agree on the "work" part, but I doubt it is "considerable".

For creating MV JARs, the 'jar' tool does all the heavy lifting.

For running Java apps, the classloader does all the heavy lifting.

For tools that have to consume JARs, the JarFile API does all the heavy 
lifting.  If you use JarFile, it's a one-line change to the constructor 
to get a version-specific view of the JAR.

So in each of these cases, the work is limited to:
  - Figure out how you intend to interact with MVJars;
  - Configure the appropriate tool (jar tool, JarFile) appropriately; 
this is generally a matter of new constructor arguments and/or new 
command line arguments.

So I totally agree there will be lots of things that change, but those 
changes should be individually quite small (and this is consistent with 
our experience supporting MVJars in the JDK tools.)




More information about the core-libs-dev mailing list