Re: Java 1.4 & Java 5 compatibility

[Kirill Grouchnikov <kirillcool@yahoo.com>]

Hi Emmanuel

Thanks for sharing your findings. Java 6 is my default choice for the projects that i'm developing (including Substance and Flamingo). While right now the concurrency APIs used in Trident are found in Java 5 as well - i make no guarantee that this will be the same going forward. I will mention this post in the announcement of the final 1.1 release.

Kirill

---

From: Emmanuel Bourg <ebourg@apache.org>
To: dev@trident.kenai.com
Sent: Tuesday, October 6, 2009 7:38:12 AM
Subject: Java 1.4 & Java 5 compatibility

Hi,

I started playing with the Trident API a few days ago and it seems well thought out, thank you for the work Kirill.

Currently Trident requires Java 6, I investigated how to downgrade this requirement to work on Java 1.4 and Java 5 (I'm maintaining a Swing application that runs on OS X 10.3.9). Here are the steps I followed if anyone is interested to create a backport.

The Java 5 compatibility is easy to get, the only Java 6 feature in the current code is the TimelineSwingWorker class which is optional. It can either be removed or reimplemented with the SwingWorker API from jdesktop. Also the compilation target must be changed to 1.5 in the build.properties file.

The Java 1.4 compatibility requires a little more work:
- turn the RunOnUIThread annotation into a standard interface
- replace the System.nanoTime() calls by Utils.nanoTime() from backport-util-concurrent
- turn the enums into standard classes with static fields
- replace the calls to Class.getCanonicalName()
- post process the jar with Retroweaver

Beyond the binary compatibility I don't know if Trident relies on behaviors specific to Java 6, but at least the backport worked fine for simple animations on Java 1.4. The backport adds a dependency on backport-util-concurrent.jar (~300k). Changing the enums is optional if you don't mind depending on the Retroweaver runtime (~180k). Retroweaver provides also a replacement for System.nanoTime(), but the alternative from backport-util-concurrent is more accurate.

Emmanuel Bourg