Question about EntryProcessor

[xavie...@gmail.com]

Hi,

I've been skimming through the JCache API and wondered if the varargs arguments on EntryProcessor were really needed?

public interface Cache<K, V> {

public interface EntryProcessor<K, V, T> {

T process(Cache.MutableEntry<K, V> entry, Object... arguments);

}

<T> T invokeEntryProcessor(K key, EntryProcessor<K, V, T> entryProcessor, Object... arguments);

}

I think having those untyped parameters is a false good idea.

If the processor is going to need some parameters, those could be passed at construction time rather than passing them as Object[] at processing time (and

casting each parameter inside the processor).

I'd rather see:

public class MyEntryProcessor implements EntryProcessor<Integer, String, Long> {

private final String parameter1;

private final Long parameter2;

public MyEntryProcessor(String parameter1, Long parameter2) { ... }

public Long process(Cache.MutableEntry<Integer, String> entry) { // do something with entry and parameters }

}

than:

public class MyEntryProcessor implements EntryProcessor<Integer, String, Long> {

public Long process(Cache.MutableEntry<Integer, String> entry, Object... arguments) {

String parameter1 = (String) arguments[0];

Long parameter2 = (Long) arguments[1];

// do something with entry and parameters

}

}

What do you think?

Regards,

Xavier

[Brian Oliver]

Hi Xavier.

While I understand where you're coming from, it raises another issue, which is hard to get around.   

Given your example (MyEntryProcessor), making the "parameters" final and private basically makes it impossible to use in a distributed caching scenario.   eg: how are the parameters passed to other JVMs, especially if the EntryProcessor is not serializable, as may be required by the implementation and as mentioned in the specification.

The reason we allow varargs is to allow vendors to provide a set of out-of-the-box EntryProcessors, that themselves may not be serializable, but the varargs are.   Yes it may be less safe in terms of parameters, but implementations are free to provide checks for this.

Fundamentally speaking, your example is not portable across implementations.   By providing varargs the capability we allow non-serializable EntryProcessors to become portable.   Without varargs we'd essentially have to make all EntryProcessors serializable in some manner, which is not desirable.

Hope this helps.

-- Brian  (co-spec lead). 

[xavie...@gmail.com]

Hi Brian,

Thank you for your explanation, now I understand.

BTW, I was really pleased to see the quality of the API (one which I have been waiting for years =).

Regards,

Xavier