JDK1.6 retro compiler

[genman]

Maybe this is more of a dev question?

I'm thinking of using some JDK1.6 classes such as java.util.NavigableMap in JBossCache. Some classes in 1.6 are already part of the backport. (This could easily be done without the 1.6 compiler.)

I am a little curious if there's any interest in having this?

The refactoring would essentially to rename ClassRedirectEditor to ClassRedirectEditor15, then create a similar ClassRedirectEditor16. (Suggestion on names?) Then create a WeaverConfiguration, which exposes a factory method to return the appropriate editors or whatnot for the configuration.

[starksm64]

Man, we barely have gotten to jdk5 support. Adding support for this in jbossretro is probably the minor issue. The bigger issue is not only having a jbossxxx project that requires both jdk5, and a jbossretro-rt6.jar. Another issue is how these future classes are being backported. Even with a java open source license, these classes cannot be merged into a jboss source tree. Is there an expanded backport project that covers both jdk5/6?

[adrian.brock]

If the actions that JBossRetro performs was made properly configurable
(see the todos in the code) rather being hardwired in a few classes
this would be a none-issue.

e.g. you can imagine being able to add to the transformations on the ant task

<retro ...>
 <transformation-classes>...ClassRedirector, JDK16ClassRedirector</>


with defaults for when this is not specified.

[genman]

A lot (if not all) of the JDK 1.6 concurrent classes are already part of the backport release. I'm not sure what classes in other packages are around.

http://dcl.mathcs.emory.edu/util/backport-util-concurrent/compatibility.php

Adrian, I think configuring the retro behavior by transformation class names is the most flexible, though I wonder if source and destination Java version would be sufficient. Was there any intention on generalizing the retro compiler into something that could be used for other purposes?

[adrian.brock]

JBossRetro is really just some ant tasks to run javassist expression editors,
class redirects and some byte code fixup over a set of classes.
(Plus another task to verify the operation, i.e. look for missing bits not retroed).

In its most generic form it would be just that, with the actions coming from
configuration, whether in the ant task itself, a properties file or some bootstrap class
that initalises what actions are done.

aopc is the same, in fact, JBossRetro is copied from JBossRetro.
Another todo is to be able to run aopc and JBossRetro in "one pass",
i.e. have a single task that does both.