JEP 238: Multi-Version JAR Files

[Joseph D. Darcy]

Note that one possible feature of JDK 9 is a -platform N option to javac 
which would allow compiling against older versions of the platform 
libraries:

     JEP draft: Compile for Specific Platform Version
     http://openjdk.java.net/jeps/8058150

This feature would address some of the concerns raised below.

-Joe

On 4/15/2015 2:24 PM, Remi Forax wrote:
>
> On 04/15/2015 02:44 PM, Paul Sandoz wrote:
>> Hi Remi,
>>
>> On Apr 15, 2015, at 1:58 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>> Hi Paul,
>>> I think you're seriously underestimate the cost of this JEP.
>> That is why we are asking for feedback :-) I want to understand the 
>> impact and get some concrete reasons why certain aspects are difficult.
>>
>>
>>> You're asking Java devs to:
>>> - be able to maintain several codes with different source level 
>>> compatibility in the same code tree.
>> Yes.
>
> Maintaining one code with a different source level than the installed 
> JDK is still not fully solved,
> i.e. you still need to have either an old rt.jar or a kind of 
> meta-description of it.
> This can be solved more easily with modules but we aren't yet there.
>
>>
>>
>>> - add a level of indirection in all tools that crawle/compile Java 
>>> source code
>>> - add a level of indirection in all tools that crawle/rewrite bytecodes
>>>
>> How common is it to statically process the byte codes of a JAR file 
>> to produce a new JAR file as opposed to doing that dynamically at 
>> runtime? (I know of obfuscating tools, which IIRC were more commonly 
>> used for mobile?)
>
> From my experience, most of tools that do rewriting at runtime are 
> able to do rewriting at compile time
> (or install time).
>
>>
>> Are processed JAR files then re-distributed via say maven or kept 
>> internally to be used with a specific stack?
>
> By example for ASM, we publish several artifacts from the same source, 
> ones are 1.3 compatible (asm.jar), others are 1.5 compatibles 
> (asm-all.jar). So users that run on embedded device can still use ASM.
>
>>
>> Would such tools process use the JarFile class to get access to the 
>> JAR file contents?
>
> either jar file or class files directly.
>
>>
>>
>>> all of that to support a feature that:
>>> - is not clearly defined
>> To me what is not clearly understood is the potential impact, where 
>> as the feature itself is actually fairly simple to grok.
>
> I agree, the idea is simple to grok, not it's perimeter.
>
>>
>>
>>> - is supposed to only solve cases where delta between versions is small
>> Yes, it's anticipated there would be a small number of classes that 
>> would require changing.
>>
>>
>>> - comes with no help from the JDK (how to detect a version, etc).
>>>
>> We can propose such things for 9. For example, new public methods to 
>> JarFile. There will be a public JDK version query API in 9, is that 
>> what you mean by "how to detect a version?", or do you mean how can 
>> one analyze an MVJAR? (or perhaps both...)
>
> How to analyze a MVJAR given that you usually have only one version of 
> the JDK installed ?
>
>>
>> Paul.
>
> Rémi
>
>>
>>
>>> While I understand the comfort for the end user to have only one big 
>>> fat jar, it would like to see a prototype that have good answers to 
>>> all these questions before including it into the JDK.
>>>
>>> Said simply, tackling such problem requires a JSR not a JEP, because 
>>> it's a feature which impact a large number of parts of the Java 
>>> ecosystem.
>>>
>>> regards,
>>> Rémi
>