I was unable to get desired results from the Retrotranslator Maven Plugin. The generated bytecode was not converted to use JDK 1.4 versions of 1.5-specific APIs. In particular, it still referenced the JDK 1.5 BigDecimal(int) constructor.
This was probably user error. But, after downloading and analyzing the source for the the Groovy-based Maven plugin, I gave up and decided it was easier to write my own, dumbed-down plugin to support the features I needed. It is called maven-jdk14-plugin, and you can find information about it here.
Here’s some information on my attempts with the original plugin.
Attempted Retrotranslator Maven Plugin usage
When using the Retrotranslator Maven Plugin, regardless of the arguments I specified, I could not get a true translation to JDK 1.4. For example,
with a <plugin> configuration element like this:
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>retrotranslator-maven-plugin</artifactId> <executions> <execution> <goals> <goal>translate-project</goal> </goals> <configuration> <attach>true</attach> </configuration> </execution> </executions> </plugin>
the resulting bytecode always used the JDK 1.5 BigDecimal(int) constructor.
Retrotranslating from the command line
The problem appears to lie with the plugin, because using retrotranslator from the command line did the trick. The line has been split for readability:
java -jar c:\Retrotranslator-1.2.8-bin\retrotranslator-transformer-1.2.8.jar -srcjar target\retro-0.0.1-SNAPSHOT.jar -destjar target\retro-0.0.1-SNAPSHOT-jdk14.jar -embed ca.freewill.retro.internal
But, this solution requires that each developer or build machine have the correct version of retrotranslator installed in the same location, or at least accessible in some consistent way, e.g. via an environment variable.
Conversely, dependencies expressed in a Maven plugin are downloaded and available from the local Maven repository. So a Maven plugin-based solution is definitely preferable to execution from the command line.