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?
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.
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.
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?
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.