I am indeed working on the assumption of Java 5 for FastList. It is
going to be very difficult to get the combination of speed and solid
correctness without depending on the Java 5 memory model, specifically
the volatile guarantees, and on atomics.
The current implementation is subject, under sufficient stress, to
intermittent dropped entries and NullPointerException failures. Although
these problems are easiest to reproduce by stress testing FastList
directly, the investigation was triggered by an isolated failure of an
Outrigger JavaSpaces QA stress test.
I suggest a formal vote on Java 5 for servers ASAP, so that we know
where we are.
Patricia
jgr...@simulexinc.com wrote:
My understanding was that we had decided to require Java 5 or 6 for servers
(owing mostly to the concurrent packages), though the client-side requirements
were left unresolved. I thought Java 5+ items were being used in the ongoing
FastList refactor.
If I was mistaken, obviously some of what I did was invalid.
jamesG
-----Original Message-----
From: "Niclas Hedhman" <nic...@hedhman.org>
Sent: Wednesday, December 29, 2010 11:49am
To: river-dev@incubator.apache.org
Subject: Re: light refactoring
On Wed, Dec 29, 2010 at 2:37 PM, <jgr...@simulexinc.com> wrote:
Replacing iterator usage with the enhanced for loop (for each).
Added generic usage to internal methods/fields. (Internal use appeared to be
non-controversial, and might ease future development.)
Removed unused imports.
I am curious; Has there been a "move to Java 5" decision already??
Cheers
