-
1. Re: usage of java.util.concurrent in place of EDU.oswego...u
kabirkhan Apr 4, 2006 7:05 AM (in response to manik)Doesn't JBoss Retro do this?
-
2. Re: usage of java.util.concurrent in place of EDU.oswego...u
manik Apr 4, 2006 7:08 AM (in response to 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 -
3. Re: usage of java.util.concurrent in place of EDU.oswego...u
manik Apr 4, 2006 7:09 AM (in response to manik)Never heard of JBoss Retro - whats this? Something on Labs?
-
4. Re: usage of java.util.concurrent in place of EDU.oswego...u
manik Apr 4, 2006 7:37 AM (in response to 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. -
5. Re: usage of java.util.concurrent in place of EDU.oswego...u
starksm64 Apr 4, 2006 8:07 AM (in response to manik)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.
-
6. Re: usage of java.util.concurrent in place of EDU.oswego...u
belaban Apr 4, 2006 12:50 PM (in response to manik)For JGroups: this whole business sounds a bit too experimental to base it on it, at least for now...
-
7. Re: usage of java.util.concurrent in place of EDU.oswego...u
manik Apr 4, 2006 1:02 PM (in response to 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. -
8. Re: usage of java.util.concurrent in place of EDU.oswego...u
manik Apr 4, 2006 1:02 PM (in response to manik)Also, I'm not talking about anything immediate - I'm looking at the JBC 2.0.0 timeframe, by end July
-
9. Re: usage of java.util.concurrent in place of EDU.oswego...u
adrian.brock Apr 7, 2006 8:35 AM (in response to manik)"bela@jboss.com" wrote:
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