JEP 238: Multi-Version JAR Files

[Stephen Colebourne]

On 1 March 2015 at 23:37, Remi Forax <forax at univ-mlv.fr> wrote:
> You only maintain one module which depend on the latest version.
> When you ship the module let say as a jar, you also ship the way to
> downgrade it as an executable code.
> At install time, when all the modules are known, before trying to create the
> images,
> the code that downgrades the module is executed if necessary.
> This code can rewrite the whole bytecodes of all the classes the module thus
> ensure backward compatibility without providing binary backward
> compatibility.

This direction certainly has potential. In many ways, the biggest
potential benefit any language could bring is the ability to handle
change of code over time (ie. its a huge potential language feature
for any new language). While we've always had deprecation, there is no
actual mechanism in code/compiler/linker terms to ensure that the
client has followed the deprecation (callers just get an error if the
code is removed). Thus, what is really needed is a standard
compiler/language mechanism to map old code to new code.

It would allow a method to be renamed (eg. Duration.getNano() to getNanos())
It would allow a class to be renamed, say java.util.Date to
DumbOldTimestampThing
It would allow an enum constant to be renamed
If done well, it might allow for much more complex refactoring
changes, but there would have to be limits

This comes under the modules banner in my eyes, because modules is
adding a linker step where this kind of stuff could be done. I hope
its on the radar (maybe fore JDK 10 rather than 9), as its a lot more
useful than MVJARs alone (which seem to have a pretty limited use, one
which could be helped over time just by making reflection easier to
use).

Note that this is slightly different to Remi's suggestion, which is
"downgrading" new code to run on an old JDK. Here I'm discussing
"upgrading" old code to run against a newer JDK. Its likely that the
both mechanisms make sense.

Stephen