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

[Galder Zamarreño]

> On 14 Mar 2015, at 09:39, Bela Ban <bban at redhat.com> wrote:
> 
> Hi Galder,
> 
> apologies for the long reply !

Haha, it's still sorter than my proposal, so not too bad :)

> 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.

I've heard a lot about ^, looking forward to seeing design doc.

I was discussing Java 8 API with others while you were having this discussion.

> 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.

You are missing essence of the proposal:

There's no unique way in which people want to access a Cache. Some people want to use ConcurrentMap, others want to use JSR-107 Cache API,  others might want to use Infinispan 7 Cache API, others just want to store data and run map/reduce jobs... 

I'm not suggesting that we change the entire Cache API. What I'm suggesting is this: Java 8 allows us the vast majority of caching use cases to be distilled into a reduced, flexible API, which can be the foundation for the facade's that we offer. 

IOW, we're not forcing anyone to use the new Cache API. If you want, you can, but the vast majority of users will use APIs they know (JSR-107, java.util.concurrent). 

It's about choice, not about having a new main API. IOW, use whatever API you want, but if youw want flexibility, we have something for you that will allow you to build more interesting data structures on top of this functional cache API.

> 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.

^ You're getting main point but you are wrongly believing that I want Functional Cache to be the main API.

Functional Cache will offer the basis to provide whatever API you want, but it should never be the first choice for users to use. 

IMO, the users of Functional Cache would be advanced users that say, want to build a distributed queue on top of Infinispan.

There should not be a main API going forward, but choice: JSR-107 API, java.util.concurrent...,etc

> 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.

+1000, that's precisely the vision I have, but again Functional Cache is not forced on them.

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

Totally.

> 
> 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...

^ Right, I think all this section needs to be rewritten to avoid confusion.

> 
> 
> "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

^ +1, performance at least for the most critical operations, e.g. put/get, needs to be at least on par.

> 
> 
> 
> "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).

^ Yeah, there's a lot of value to be added in this area. 

I was very pleased to hear about the CompletableFuture based interceptor chain discussion because I thought it'd fit perfectly with the direction of the functional cache API.

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

Ok, maybe we won't deprecate Infinispan Cache but we'll definitely won't add anything extra there. It's way too ovebloated IMO.

> 
> +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

+1 to all those.

Thanks Bela for the feedback!

> 
> 
> 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)
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com