JEP 238: Multi-Version JAR Files

[Paul Sandoz]

On Apr 15, 2015, at 2:03 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> Of course we cannot feasibly backport every new API in N to N-1, N-2 etc. In selective cases that might be possible, but for the core of the JDK it's like pulling on a string of public dependencies, internal dependencies and perhaps more subtle dependencies between javac and hotspot (Unsafe replacements would be particularly tricky).
> 
> that why most of the tools like the retroweaver [1] rewrite bytecodes because you can replace a dependency to a JDK class to wire it to a class that will come with your code.
> 

IIUC Retroweaver seemed to hit a sweet spot focusing on transforming language features and some minimal API features (i presume some lambda weaving tooling has/will hit a similar sweet spot, there is at least one but i cannot recall the name).

It seems for APIs in general this may require more sophisticated code transformation techniques with additional non-core library support?


> Note that in that case, you develop and maintain only one version of the code compatible with the newer version and backport the code to the old one, instead of selectively develop part of the code with the new version as you propose.
> 

And either one publishes X JARs for each platform, or the consumer manages that themselves. Or one trusts this to work in some dynamic fashion.

--

In my last email i forgot to point out that a tool (jar for example) that transforms a MVJAR into a platform specific JAR before being operated on by a byte code transforming tool may be a reasonable approach, but still requires some additional action.

Paul.