JEP 238: Multi-Version JAR Files

[David M. Lloyd]

On 02/25/2015 11:41 AM, Paul Sandoz wrote:
>
> 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?

I've done a little bit of work on the maven-compiler-plugin internals 
and its plexus buddies, and overall I don't think this would necessarily 
be a massive undertaking, though it might have to be, depending on some 
factors:

1) If the JDK-agnostic sources are required to be fully self-contained 
(i.e. no "outward" dependencies on JDK-specific code), it would be 
trivial to compile the JDK-agnostic code first, then the JDK-specific 
code which references the other code as dependencies.  However this 
arrangement is practically quite useless for the average developer who 
is doing this just so they could have just one JDK-specific version of 
some class used by their main code.

2) In the more likely case that the -specific and -agnostic code is 
interdependent, it gets trickier because the compiler task would have to 
(I guess) compile the code N times, once for each JDK, while also 
correlating the -specific files and discarding the redundant -agnostic 
files (leaving aside weirdness that may occur if the files actually 
*differ* due to constant expansion weirdness and so on).  This thought 
leaves me feeling not so great - it seems like there are many subtle 
ways it could fail.

3) The best scenario however is that JavaCompiler will magically do all 
this work for us, figuring out (for example) the constant stuff and 
other potential weirdness, and then organizing the resultant .class 
files in their appropriate places based on some input 
configuration/cooperation with the JavaFileManager for the task.  In 
this case I'd imagine that the maven-compiler-plugin would work as 
today, with just a few extra switches to point out the JDK-specific 
source directories, and Maven would be blissfully ignorant of any other 
considerations.

-- 
- DML