usage of java.util.concurrent in place of EDU.oswego...util.

[manik]

Reference: http://jira.jboss.com/jira/browse/JBCACHE-522

Does anyone have any thoughts/ideas on this?

There are 2 key drivers here:

1. When running under Java5, concurrent.jar is unnecessary and just adds to bloat

2. concurrent.jar's undefined license makes it tricky for adoption in some organisations (some of who would rather go through an overall upgrade to Java5 just to get around concurrent.jar!)

The way I see it, since we currently mandate Java5 for building JBossCache anyway, the source code should baseline to using java.util.concurrent. We should simply build 2 packages - JBossCache-dist-JDK1.4.zip and JBossCache-dist.zip, where the 1.4 version preprocesses classes to replace java.util.concurrent calls with concurrent.jar equivalents and includes the additional jar file.

Does anyone know of any preprocessing tool or script that could do this? Or would we have to write one ourselves? Retroweaver (http://retroweaver.sourceforge.net) does *not* do this - it only translates language features such as autoboxing, generics, etc. Not API level translation.

Bela, it also occured to me that you may have to do something similar in JGroups if JBoss Cache were to be able to ship/run without concurrent.jar ...

Thoughts?

Cheers,
Manik

[kabirkhan]

Doesn't JBoss Retro do this?

[manik]

Just found RetroTranslator (as opposed to RetroWeaver!!) which does support both language features as well as APIs.

http://retrotranslator.sourceforge.net/

It even comes with an ANT task to do the dirty work, so building 2 distribution sets should be easy.

Thomas D and Scott S have been playing around with this as well - see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=74844

[manik]

Never heard of JBoss Retro - whats this? Something on Labs?

[manik]

Ok, thanks to Adrian for this - http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossRetro

I'll give this a go when I have a moment.

[starksm64]

Use or jboss retro would only replace one concurrent jar with another one (backport-concurrent), and introduce a dependency on two others: jbossretro-rt.jar and javassist.jar. Only a pure java5 dependent release would not have any additional dependency.

[belaban]

For JGroups: this whole business sounds a bit too experimental to base it on it, at least for now...

[manik]

Not much point then with JBossCache - if JGroups still brings in concurrent.jar as a dependency. :)

I'd say we find a solution for both JGroups and JBossCache together, implement them side by side as well since whatever we do to implement this will probably be very similar if not the same.

[manik]

Also, I'm not talking about anything immediate - I'm looking at the JBC 2.0.0 timeframe, by end July

[adrian.brock]

For JGroups: this whole business sounds a bit too experimental to base it on it, at least for now...

JBoss Retro is mostly byte code weaving to replace JDK5
classes with replacements.

Most of those replacements come from the backport-concurrent-util
project http://dcl.mathcs.emory.edu/util/backport-util-concurrent/
Which is based on the same public domain code as JDK5
written by Doug Lea and other members of the JSR 166 spec comittee.

Although backport-concurrent-util isn't complete (it doesn't handle
things the whole api) because some of it requires changes to the
memory model. Some are workaround by falling back to
old fashioned synchronization.

The retrocheck task will spot these and give you an error if you try to use them. It checks for any unweaved JDK5 api.

I even suggested making a "smoke test" that runs the JSR166
public domain stress tests, to validate that a user's platform
does actually support concurrency properly. See the note at the bottom
of here :-)
http://dcl.mathcs.emory.edu/util/backport-util-concurrent/robustness.php