On 04/15/2015 02:59 PM, Paul Sandoz wrote:
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'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
