JEP 238: Multi-Version JAR Files

[Remi Forax]

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