JEP 238: Multi-Version JAR Files
paul.sandoz at oracle.com
Wed Apr 15 12:44:46 UTC 2015
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.
> - 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...)
> 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.
More information about the core-libs-dev