Re: [javagroups-users] JDK 5 as baseline for JGroups 2.5

[Bela B. <be...@ya...>]

OK, thanks for the information. Since this bug was fixed in March 2005, 
I don't see why this should not be part of JDK 5 (Tiger), rather than 
JDK 6 (Mustang) ? Do you know whether this has been backported to JDK 5 
(latest SP) ?

I'm mainly interested in JDK 5's thread pools, but possibly their impl 
uses reentrant locks internally...

Anton Mironenko wrote:
> Hi Bela,
>
> Friday, November 24, 2006, 12:18:35 PM, Bela wrote:
>
> BB> I'm tempted to base JGroups 2.5 on JDK 5 as baseline. The reasons are
>
> BB>     * JDK 5 is so much better than JDK 1.4, has more functionality (e.g.
> BB>       util.concurrent rather than EDU.concurrent, compare-and-swap) and
> BB>       is faster too
> BB>     * It looks as if we (Red Hat) might support JGroups 2.4 for 3-5
> BB>       years, and JDK 1.4 will be EOL'ed before that
> BB>     * JGroups 2.5 is planned for March/April 2007, and by then JDK 1.4
> BB>       is even older
>
> BB> Can you let me know if you absolutely need JGroups to support JDK 1.4, 
> BB> or if you're fine with JDK 5 ?
>
> Recently we discovered the bug with leak of objects
> java.util.concurrent.locks.AbstractQueuedSynchronizer$Node
>
> It seems like we observed the Sun's bug
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6236036
> (this is supposed to be fixed in 1.6)
>
> This was because we used
> java.util.concurrent classes, for example,
> java.util.concurrent.locks.ReentrantReadWriteLock
>
> Then we changed our code back to
> EDU.oswego.cs.dl.util.concurrent.ReentrantWriterPreferenceReadWriteLock
>
> and the problem was solved.
>
> So java.util.concurrent is not as robust as EDU yet,
> It'd ragher not hurry up the migration to java.util.concurrent.
>
>   

-- 
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat