[concurrency-interest] Subject: Re: ConcurrentHashMapV8

Peter Firmstone peter.firmstone at zeus.net.au
Sun Oct 9 08:20:07 EDT 2011

Thanks Doug, I don't know much about lambdas, I'm confident you'll
figure out the right solution.

The following is another similar interface which permits early



 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership. The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License. You may obtain a copy of the License at
 *      http://www.apache.org/licenses/LICENSE-2.0
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * See the License for the specific language governing permissions and
 * limitations under the License.

package org.apache.river.api.util;

import java.io.IOException;

 * This interface is similar to an Enumerator, it is designed to return
 * results incrementally in loops, however unlike an Enumerator, there
is no
 * check first operation as implementors must return a null value after
 * the backing data source has been exhausted. So this terminates like a
 * by returning a null value.
 * @author Peter Firmstone
public interface ResultStream<T> {
     * Get next T, call from a loop until T is null;
     * @return T unless end of stream in which case null is returned.
    public T get() throws IOException;
     * Close the result stream, this allows the implementer to close any
     * resources prior to deleting reference.
    public void close() throws IOException;

> Message: 1
> Date: Sat, 08 Oct 2011 08:02:18 -0400
> From: Doug Lea <dl at cs.oswego.edu>
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Subject: Re:  ConcurrentHashMapV8
> Message-ID: <4E903BCA.7090104 at cs.oswego.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 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

More information about the Concurrency-interest mailing list