Generic writer/outputter. What Reader is to Iterator, what is Writer to X?

Question

In Java the abstract version of a Reader that works with pulling Objects (instead of characters) is an Iterator.

The question is there an abstract version of Appendable or Writer where I can push objects (ie an interface)?

In the past I just make my own interface like:

public interface Pusher<T> {
    public void push(T o);
}

Is there a generic interface that is available in most environments that someone knows about that makes sense so I don't have to keep creating the above interface?

Update:

Here is an example of where it would be useful:

public void findBadCategories(final Appendable a)  {
    String q = sql.getSql("product-category-bad");
    jdbcTemplate.query(q, new RowCallbackHandler() {
        @Override
        public void processRow(ResultSet rs) throws SQLException {
            String id = rs.getString("product_category_id");
            String name = rs.getString("category_name");
            if (! categoryMap.containsKey(id)) {
                try {
                    a.append(id + "\t" + name + "\n");
                } catch (IOException e) {
                    throw new RuntimeException(e);
                }
            }
        }
    });
}

I'm using an Appendable here but I would much rather have my Pusher callback. Believe me once Java 8 comes out I would just use closure but that closure still needs an interface.

Finally the other option I have chosen before is to completely violate Guava's Predicate or Function (although that seems even worse). Its violation of the contract because these aim to be idempotent (although I suppose if you return true all the time... ).

What Guava does provide though is sort of analagous to Python's generators thanks to its AbstractIterator.

I added an enhancement issue to Guava but I agree with them that its not really their job to add something fundamental like that.

Answer 1

On several projects now, I've defined for this purpose what I call a sink:

interface Sink<T> {
  void put(T contribution);
}

With that, methods that produce objects of type T would demand a parameter of type Sink<? super T>.

Several design questions arise:

• As declared, Sink#put() throws no checked exceptions. That doesn't play well with I/O operations that usually throw IOException. To address this, you can add a type parameter that extends Exception and advertise that put() throws this type, but at that point, if you know that much about the nature of value consumption, you're probably better off defining a custom interface for it.

• As declared, Sink#put() does not return a value. It's not possible to indicate to the caller whether the value was accepted or not.

• With a generic interface like this, you're forced to box contributions of primitive types like int and char, which also means they can be null. Consider annotating the contribution parameter with @NonNull.

To go along with this type, related to the generator concept that Petr Pudlák mentions in his answer, I've defined a source interface:

interface Source<T> {
  T get();
}

Methods looking to draw items of type T from such a source demand a parameter of type Source<? extends T>.

For coordination with channels among concurrent processes, I've defined both Sink#put() and Source#get() to throw InterruptedException:

interface Sink<T> {
  void put(T contribution) throws InterruptedException;
}


interface Source<T> {
  T get() throws InterruptedException;
}

These are analogous to Doug Lea's original Puttable and Takable interfaces that didn't make it into the java.util.concurrent package, though lacking in an equivalent to the timed wait Puttable#offer() and Takable#poll() methods.

All sorts of implementations then arise that can be composed easily, such as exchangers, filters, and transformers.

Beyond my own library, I've seen the Guava library provide the PrimitiveSink and Funnel types for hashing-related purposes. You may find those to be useful abstractions as well.

Answer 2

There can be several views on the subject:

1. The dual of an iterator is a generator. Iterators "consume" values from a collection, generator "provide" them. But generators are a bit different than writers. For a writer, you decide when you push an element into it. On the other hand, generators provide you with a sequence of values, one by one. Java doesn't have any specific language support for generators. See also What is the difference between an Iterator and a Generator?

2. The opposite to iterators is something you could push values into. I don't think Java has any abstraction for that. The closes I have seen is Scala's Growable (neglecting the clear() method).

Answer 3

The closest is Observable but it isn't used so much.

public update(Observable o, Object arg)

I would not use Iterable instead of Reader and I would create a consumer of your choice.

A common pattern is to not use an interface but rather an annotation.

e.g.

@Subscriber
public void onUpdate(Update update) { }

@Subscriber
public void onInsert(Insert insert) { }

@Subscriber
public void onDelete(Delete delete) { }

When this class is added as a listener it subscribes to Update, Insert and Delete objects, and ignores any others. This allows one object to subscribe to different type of message in a Type safe way.

Answer 4

Here is what I decided to do (and I think its the best option out of what others gave :P ).

I'm going to backport Java 8's Lambda classes (java.util.functions.*). Particularly this one:

/**
 * Performs operations upon an input object which may modify that object and/or
 * external state (other objects).
 *
 * <p>All block implementations are expected to:
 * <ul>
 * <li>When used for aggregate operations upon many elements blocks
 * should not assume that the {@code apply} operation will be called upon
 * elements in any specific order.</li>
 * </ul>
 *
 * @param <T> The type of input objects to {@code apply}.
 */
public interface Block<T> {
/**
 * Performs operations upon the provided object which may modify that object
 * and/or external state.
 *
 * @param t an input object
 */
void apply(T t);

// Some extension methods that I'll have to do with below.
}

Basically I'll make a new namespace like com.snaphop.backport.java.util.functions.* and move over the interfaces and make them work with Guava. Obviously I won't have the lambda syntax or the extension methods but those I can work around. Then in theory when Java 8 comes out it all I would have to do is a namespace switch.