[infinispan-dev] Cache Java 8 API proposal - First draft

[Bela Ban]

Hi Galder,

apologies for the long reply !

imo the value of Java 8 is:

#1 Reduction of implementation code (streams and internal iteration)

#2 Making some of the APIs simpler, e.g. distributed executors, map-reduce

#3 Reactive programming, e.g. interceptor chain (discussed in Berlin), 
non-blocking behavior; the goal being to reduce the number of threads 
required.

However, changing the entire Cache API is going too far atm. Now that 
we've finally provided a Cache/JSR107 API, people are familiar with it 
and I would not change it, at least not right now.

If we're able to use reactive programming (e.g. your eval() function) 
*under the cover*, then all the better.

If your proposal is about providing FunctionalCache and implementing 
Cache and JSR 107 Cache with it, then you have my +1. But IMO 
FunctionalCache should not be the main API.

Compare FunctionalCache.eval() to ioctl() for a moment: of course, every 
access to a file system can be implemented via ioctl(), but people like 
the simplicity of write(), read(), stat() etc.

So providing eval() *only* shifts the burden of implementation to the 
user. But I agree that perhaps it's a good thing to expose 
FunctionalCache so power users (e.g. Sanne :-)) can use it directly to 
implement functionality not provided by Cache.

Being able to switch to Java 8 doesn't imply we have to use all of its 
new features.

Let me address your proposal step by step.



"What's wrong with the Infinispan Cache API?"
--------------------------------------
- Nothing !
- I can't follow your argument as to why Cache is bad. This is the 
premise to your proposal and it needs to be very clear !
- JSR 107 came up with a similar API. So if we have to change Cache, 
then I'd +1 a change to JSR 107 as main API
- I don't see why it's difficult to add new operations: distributed 
queues should be a separate API anyway, and not extend Cache ! We should 
use CacheManager to get a new DistributedQueue, as we do to get a new 
Cache...


"How does Java 8 improve on this?"
------------------------------
- Passing serialized lambdas around sounds awfully familiar: it's the 
old 'agent-based programming' paradigm fashionable before the turn of 
the millenium. Instead of invoking RPCs which carry data on P, code 
(also carrying data) is shipped to P and executed there and the result 
sent back to the invoker. (Disclaimer: I wrote such a system myself with 
GOMScript... :-().
I'm not saying this is bad, but we have to make sure that
(a) Infinispan benefits from this either in code reduction / 
maintainability / code simplification
(b) performance doesn't decrease



"Proposal"
---------
- Returning a CompletableFuture is a good idea: +1
- I think this is where the main value of your proposal lies: being able 
to chain functions (lambdas) together, that are invoked turn-by-turn, 
possibly by different threads, without a caller having to block
- The F.invoke(G).andThenInvoke(H).andThenInvoke(I) pattern (where F is 
a future and G,H,I are lambdas) is very valuable to implement 
non-blocking behavior: whenever a function (lambda) has to block, it 
registers a function with the blocking resource that's called upon 
unblocking and the thread terminates and is added back to the thread pool
- Blocking can be waiting to read from the file system or network, or 
trying to acquire a lock etc
- As was discussed in Berlin, the interceptor chain could be rewritten 
using CompletableFutures (or sth similar).


Summary
--------

I'd not make FunctionalCache the main API and I'd definitely not 
deprecate Cache.

+1 on providing FunctionalCache as a (parent) interface to Cache, so 
power users can use FunctionalCache if needed.

+1 on implementing Cache and JSR 107 Cache with FunctionalCache.

This should only be done if:
- Performance remains at least as good as it is now [mandatory]
- Maintainability increases [nice]
- Code reduction [nice]

My 5 cents


On 13/03/15 09:10, Galder Zamarreño wrote:
> Hi all,
>
> We're starting to work on some prototypes for the Java 8 API coming up in Infinispan 8.
>
> I've written a design wiki for a replacement of our main embedded Cache interface that takes advantage of Java 8 improvements:
> https://github.com/infinispan/infinispan/wiki/Java-8-API-proposal
>
> It'd be great to hear your thoughts.
>
> Proposals for Java 8 versions for cache manager, remote cache and other external APIs are yet TBD.
>
> Regards,
> --
> Galder Zamarreño
> galder at redhat.com

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)