JEP 238: Multi-Version JAR Files

[Remi Forax]

On 04/15/2015 02:59 PM, Paul Sandoz wrote:
> 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's harder to write a rewriter from 1.8 to 1.7 because lambda means 
Stream and collection.stream() means default method which is hard to 
simulate just using bytecode rewriting
(the only way I know is to use invokedynamic for that which is fun but 
will require a lot of testing).

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

yes

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

Rémi