Backport Java 5/6 features to Java 1.4?

Question

We are stuck with Java2SE v1.4 till the end of 2010. That's really nasty, but we can't help it. What options do we have to use some of the new features already now? I can think of several ways like

• changing the bytecode, e.g. using Retrotranslator or Retroweaver.

• backport of libraries, e.g. Concurrent Backport, but this does not help for generics.

• emulation of Java 5 features, e.g. checked Collections, Varargs with helper methods, etc.

• changing source code by precompilation, stripping all 1.5 stuff before final compilation, e.g. using Declawer can do this.

I am most interested in very positive experience with it in production environments using Weblogic and "real" stuff.

Renwick

to be really picky...there never was a Java 4, it was Java 2 release 1.4. – Dellinger

Yeah because Sun's marketing names are logical. – Tricorn

Thanks for editing the tags. I searched SO but did not find the related questions: - #604328 - #548372 - #18493 – Renwick

When you do upgrade, make sure its not to Java 5.0 as this has been EOLed for a year now. Upgrading comes at a price, but failing to upgrade also comes at a price. – Matrices

Sun's marketing names have a logic of their own, they just don't match the internal names which are kept for backward compatibility, Just look at the Windows version names/numbers. We had Windows 2000, tens years ago and now we have Windows 7. – Matrices

BTW: Being perdantic, there was no Java 1.5 or Java 5. It was Java 5.0, followed by Java 6. – Matrices

Answer 1

Thanks for your answers. Here is the summary of all relevant answers and my own research.

Changing the bytecode: The Retros
This is done by the "retro"-tools: Retrotranslator, Retroweaver and JBossRetro. Retrotranslator seems to be the most mature and active of them tool. These tools scan all classes and change the bytecode to remove Java 5 and 6 features. Many Java5 features are supported, some by using 3rd party backport libraries. This option is most popular and there is some positive feedback from users. Experiments showed that it's working as expected. See a short overview on developerworks.

Pro: You can develop entirely in Java 5, build modules and all kind of JARs. In the end you just transform all classes to Java 1.4 and package your EAR. This is easily done with Retrotranslator's Maven integration (org.codehaus.mojo:retrotranslator-maven-plugin).

Con: Conservative environments do not allow changed bytecode to be deployed. The result of the retro-step is not visible to any coder and can't be approved. The second problem is fear: There might be some cryptic production problem and the retro-code is another step that might be blamed for that. App-server vendors might refuse help due to changed bytecode. So nobody wants to take responsibility to use it in production. As this is rather a policital than a technical problem, so I see no solution. It has happened to us, so I was looking for further options :-(

Compiling Java5 to Java 1.4: jsr14
There is an unsupported option, javac -source 1.5 and -target jsr14 which compiles the Java5 source to valid Java 1.4 bytecode. Most features like varargs or extended for loop are translated by the compiler anyway. Generics and annotations are stripped. Enums are not supported and I don't know about autoboxing, as the valueOf methods were mostly introduced in Java5.

Con: Only byte code is translated, library usage is not changed. So you have to be careful not to use Java5 specific APIs (but could use Backports). Further you have to build all modules at the same time, because for development time you propably want Java5 code with generic and annotation information. So you have to build the entire project from scratch for Java 1.4 production.

Changing Source back to Java 1.4: Declawer
As answered in a related question, there is Declawer, a compiler extension, that works for generics and varargs, but not for enhanced for loop or autoboxing. The generated source "is a little funky, but not too bad".

Pro: The generated source is available and can be reviewed. In worst case fixes can be made in this source. There is no "magic", because the source is valid Java. Some people even use JAD (Java decompiler) to get the Java 1.4 source again. The output of Jad readable is readable if you compile with debug information and don't use inner classes.

Con: Similar to -target jsr14, you need an extra step in the deployment. Same problems with libraries, too.

Changing Source back to Java 1.4: by hand
Several answers suggested doing it by hand. For an automatic, repeating build process this is of course not useful, but for one-time changes it's reasonable. Just automate what is possible. Maybe look at Antlr for creating a home-grown conversion tool.

Backported Libraries:
The problem is, that Java5 also ships new libraries, that are not available in older JREs, see related question. Fortunately there are several backported libraries that give you some functionality of Java5, but can't simulate language features, like generics.

• Annotations, discussed at TSS
• Concurrent
• com.sun.net.httpserver (Java 6 to 5)
• Gif writing (Java 6 to 5)
• Start your own backport project ;-)
• You might copy classes you need from the JDK or other libraries, but most likely they are related to other classes.

Emulating Java5 features in Java 1.4 code:
I was thinking about some things you might do to make your life easier and still staying with Java 1.4. The most important features are typesafe collections, here are some ideas:

• Instead of using generics you can create your own typesafe containers with some template.
• Add a typesafe Iterator (which is no Iterator any more).
• Add asList methods that allows 1,2,...,n arguments and an array of them (to simulate varargs).
• Methods for varargs (converting 1,...,n arguments to arrays) and valueOf can be put in some helper class.

Renwick

Compiling entire project from scratch for Java 1.4 production should be handled by your build server. – Unloose

Most of these are now out of date. Is there an equivalent for 6->5? – Chinn

Retrotranslator should be able to do 6->5. I tried it with HSqlDB 2. Unfortunately it does not handle the new java.sql classes, so it failed. But if you do not use any Java 6 API, give it a try. – Renwick

@Peter Kofler the related question and declawer link is broken. – Scotsman

Answer 2

sourcecode precompilation, stripping all 1.5 stuff before final compilation and deployment. Are there any tools which can do this?

Yes. They're called Retrotranslator or Retroweaver. Apart from Generics (which only exist for the compiler's sake anyway), you cannot simply "strip 1.5 stuff". Enums (and maybe also some other features) have to be replaced with functionally equivalent code. Which is exactly what those tools do.

Jubbulpore

Retrotranslator or Retroweaver change the bytecode as listed above. es I agree, not all features will be able to be used. Generics on their own would be a big win already. – Renwick

Answer 3

You can code with JDK 1.5 features and target JDK 1.4 at compile time. See available Javac options. However, most libraries are now using JDK 1.5 code, so you'll be stuck with old libs.

Handtohand

I may be mistaken, but targeting an older source level (1.4 in this case) restricts you to only using the features in that source level. Please correct me if I am wrong. Perhaps we are referring to different settings, could you add more detail to your answer? – Tricorn

I was told so too, but I am not able to make it work. Usually Source=1.5 needs Target=1.5 in Eclipse and for plain Sun's javac in the command line. – Renwick

You can use the flag -target jsr14 – Handtohand

Answer 4

It worth noting that while Java 1.4 has been EOL for some time. Java 5.0 will be EOL Oct 8th, 2009. If anyone is promising you Java 5.0 by 2010, I would ask why?!

Matrices

Where I work, we're still stuck with 1.4 as well, though the promise is to switch this year. Large companies are way more conservative and reluctant to change working systems than the people who dream up EOL dates at tech companies imagine. Or maybe those people simply know that said companies are also willing to pay good money for extended support contracts. – Jubbulpore

-1 because it does not help me. I know that we should upgrade and I am the first person to say so to management. – Renwick

I worked for a company with 65K employees and now for one with 139K employees and they are only just upgrading to Java 6 on all PCs so I know it can be slow, but Java 5.0 has been available for 5 years, and Java 6 for 2.5 years. Java 7 is likely to available by 2010. I don't think working for a big company is a good excuse. If you have a business case for using a supported/current version of Java you should make one. – Matrices

EOL's are for limiting support, not for stop using. We still regularily deploy on Java 1.4. – Unloose

Some people still use Java 1.3. That doesn't make it a good idea. – Matrices

Answer 5

To simulate annotations in java 1.4 you can use http://xdoclet.sourceforge.net/xdoclet/index.html

Seine