On Apr 15, 2015, at 2:03 PM, Remi Forax <fo...@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.
