On 1 March 2015 at 23:37, Remi Forax <fo...@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
