JEP 238: Multi-Version JAR Files

[Paul Sandoz]

On Feb 25, 2015, at 5:27 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> 
> 
> 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.)
> 

In the design doc i outlined how to explicitly compile an mv-style project.

How hard would it be to hack up a new kind of maven project layout and javac compilation task that did something similar? 

Does anybody with maven expertise know more?

Paul.