[concurrency-interest] Subject: Re: ConcurrentHashMapV8

Jed Wesley-Smith jwesleysmith at atlassian.com
Sun Oct 9 17:32:50 EDT 2011


The functional/persistent Stream interface is a great alternative that
doesn't rely on null being magic:

Stream<T> {
  T get(); // throws if empty aka head()
  Stream<T> next(); // aka tail()
  boolean isEmpty();
}

implementations can be strict or lazy, but each actual instance is
referentially transparent.

this interface works well in conjunction with Option/Some (or Guava's
Optional).

On Sat, Oct 8, 2011 at 11:02 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 10/08/11 06:26, Peter Firmstone wrote:
>
>> With Reference to Iterators, why not do something like this:
>>
>> interface AtomicIterator<T>  extends Iterator<T>{
>>     T getIfHasNext();
>> }
>>
>
> Back in pre-JSR166 days, I considered uniformly using
> a stream-like interface style along these lines for concurrent
> collections instead of Iterator, to avoid the hasNext/next
> non-atomicity problem in a classic way similar to IO and
> channel APIs.  Recasting without the Iterator connection:
>
> interface ElementStream<T> {
>  T next(); // return next element, or null if there aren't any
> }
>
> This works in part because nulls are generally disallowed
> in concurrent collections. (An ElementStream for an
> array-like collection like CopyOnWriteArrayList that
> can legitimately contain null gaps would need
> to internally skip over them when presenting next().)
>
> It also meshes nicely with the various Queue APIs -- Queue.poll
> is a "mutative" version of next() that also removes the element.
>
> At the time of JDK5/JSR166, it was more important to integrate
> concurrent collections with plain java.util collections, so
> we didn't pursue this. And even though signature-wise, you
> could claim that Iterator extends ElementStream, the
> null-means-exhausted rule makes them incompatible.
>
> But with the advent of lambdas and bulk parallel operations,
> it might be worth considering this as a way of supporting
> stream-style processing in addition to forEach-style processing.
> Which would amount to giving people two choices for how they'd
> like to replace all their sequential iterator code. Or,
> to allow gradual adoption at the expense of messiness,
> supporting all three styles.
>
> -Doug
>
>
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111010/30e0a251/attachment.html>


More information about the Concurrency-interest mailing list