[concurrency-interest] backport: Is there a forward port
ofbackport.util.concurrent to Java 5.0
mark.kralj-taylor at zen.co.uk
Wed May 11 19:01:46 EDT 2005
I understand that porting from backport.util.concurrent to
java.util.concurrent means replacing import statements, but this is not
practical for us, let me try and elaborate...
Also my users want to avoid runtime and learning overhead of that an
abstraction API would introduce:
- java.util.concurrent classes defines the API.
-- We definitley don't want a 'Jakarta Commons Concurrent' API that
detects if you are using Java 5 at runtime - we are happy to make
decision at deployment time, just not design (coding) time.
- backport.util.concurrent provides a way to use java.util.concurrent
API with Java 1.4, tahts great, ok it uses different packages because
java.* is special, thats fine.
-- I'm ok with import statement translation when we upgrade to require
upgrade to Java 5, but we are not ready for that yet .....
Our situation today is of many in-house aplications owned by seperate
teams that will each make their own decision on which JVM they run with:
is it Java 1.4 or 5.0 and which JVM vendor: SUN, IBM, BEA....
There are many shared libraries owned by seperate teams again, and some
of these want to use java.util.concurrent constructs (previously we used
Some library APIs use low level concurrency constructs, exposing them to
higher levels - esp. Futures, Executors etc. we don't want to write
custom abstraction APIs and Java 1.4/5.0 integrations for these.
End result is that an app is a stack of 10+ libs (many in-house).
At an application groups level, projects want to chose which JVM to run
with and if Java 5.0, to get performance advantages of JVM support for
atomic operations (i.e true non-blocking data structures in
java.util.concurrent on Java 5.0 - we have seen performance benefits
from using atomic-operations CAS etc in C++)
A forward port of backport-util-concurrent.jar would enable projects to
take advantage of Java 5.0 by changing a single JAR on their classpath,
this is do-able and control of each application group.
However maintaining and deploying an entire stack of library Jars with
different import statements is not something we see as manageable.
When we can require minimum of Java 5.0, updating imports will be fine,
but this is some time off, probably more than a year given we will be
moving to require Java 1.4 (rather than 1.3) in the NEXT few months -
and some see that as being aggressive!
I hope tis helps explian why we are interested in a forward port of
backport-util-concurrent.jar, and why we don't see replacing import
statements as a solution for us in the medium term.
Dawid Kurzyniec wrote:
> 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
>>> 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
>>> 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
>>> 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
>>> 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