JEP 238: Multi-Version JAR Files

[Peter Levart]

On 02/25/2015 05:27 PM, Brian Goetz wrote:
>
>
> On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
>>
>>
>> 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.)
>

One aspect that is overlooked here is the "coding phase" which is 
nowadays performed in IDEs. Refactoring and such. One would like to have 
all versions of a particular class targeting distinct platforms 
accessible in IDE not only for primitive text-editing, but also for 
refactoring. IDEs currently don't like seeing multiple versions of same 
class at the same time. Supporting this in an IDE is a considerable work 
to do, I think, and requires IDE to "understand" multiple source files 
for same class name as distinct versions of the same class which it must 
keep in sync regarding the public API of the class. I don't think any 
IDE has this mechanisms in place currently, but I might be wrong. Does 
anybody know?

Peter