[concurrency-interest] backport: Is there a forward port ofbackport.util.concurrent to Java 5.0

Dawid Kurzyniec dawidk at mathcs.emory.edu
Wed May 11 12:34:34 EDT 2005

Hanson Char wrote:

>Sounds like it should belong to a separate project, analogous to the
>Apache commons logging which acts like a facade to the actual
>underlying implementation.  So kind of a "commons concurrent" package
>which provides an API that allows either the backport or jdk1.5 to be
>used, depending on the actual JVM being run.
That sounds right. My suggestion would be that you create your own 
facade API, with the stuff that you use, in versions for 1) backport and 
2) j.u.c., differing by import statements. An alternative is to try to 
recompile backport with changed package names, e.g. removing 
"edu.emory.mathcs.backport", and add the JAR to the _boot_ class path on 
1.4 JVMs (although I am not even sure if this will work, e.g. JVM may 
complain about forbidden definition of java.* packages). If this works, 
you could use j.u.c. APIs in 1.4, with the exception for things like 
nanoTime(), as Doug mentioned.

The "forward-port" of the backport is another interesting alternative, 
but I am not sure how happy people would be to code against backport 
packages (funny package names, no generics etc) when targetting mainly 
5.0. Also, this potentially could add overheads (as could, as the matter 
of fact, the facade API) - e.g. if delegation is used, calls would go 
through wrapper classes, and also the number of instance counts would 
double, which could be non-negligible for lock classes and atomic 
variables. Possible solution would be to use inheritance, rather than 
delegation. I might consider something like this at some point, but the 
priority for me is to complete the backport (e.g. add skip-list maps).

BTW. I am happy to see such a wide interest - people are asking for the 
backport to be available on all Java versions between 1.3 and 5.0 :) I 
will try to do my best to accomodate the requests, with priorities 
depending on the relative level of interest.

Dawid Kurzyniec

>On 5/11/05, mark.kralj-taylor <mark.kralj-taylor at zen.co.uk> wrote:
>>Is there a forward port to Java 5 of the backport.util.concurrent libraries?
>>At first this might sound a strange requrest, if running a Java 5 JVM,
>>why not just use java.util.concurrent directly?
>>I want to use java.util.concurrent style APIs in my libraries, but I
>>don't control the level of JVM the code will eventually be run in.
>>This is typical for large systems that are composed to a mixture of open
>>source and in-house Jars from several project teams.
>>I have to write to the minimum JVM level that we support (Java 1.4),
>>then other projects will choose to deploy to either a Java 1.4 or 5.0 JVM.
>>I don't have cycles to maintain seperate Java 1.4 and 5.0 sources or
>>libraries I work on.
>>It would be great if I could code to backport.util.concurrent API, then
>>projects could choose between a Java 1.4 and Java 5.0 implementation Jar
>>of  backport.util.concurrent, to match their JVM.
>>The benefits of a Java 5 forward port of java.util.concurrent, is that
>>it lets people take advantace of an implementation optimised for Java 5
>>atomic operations, if they are running a Java 5.0 JVM, without needing
>>them to make any code changes.
>>Right now my libraries are leading projects to use
>>backport.util.concurrent APIs, which is a performance compromise on Java
>>5.0 JVMs.
>>Ideally a forward port would allow interoperability between
>>java.util.concurrent and backport.util.concurrent.
>>What is the backport.util.concurrent project's thoughts on this?
>>Are there any plans to Java 5 produce a forward port?

More information about the Concurrency-interest mailing list