JEP 238: Multi-Version JAR Files

[Paul Sandoz]

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.


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

Are processed JAR files then re-distributed via say maven or kept internally to be used with a specific stack?

Would such tools process use the JarFile class to get access to the JAR file contents?


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


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

Paul.


> 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