On 03/23/2017 02:52 PM, Dan Berindei wrote: > Ideally I'd like to properly support non-serializable lambdas, too, by > using conditional write operations and retrying if unsuccessful. If > that turns out to be too tricky, we could also support > non-serializable lambdas for local caches only, and throw an exception > if the cache is clustered.
At least we should voice a warning log if the operation requires to be handled using conditional ops. > > I'm not sure if we should overload the method (like the streams API > does) or create new methods though, because Java 9 seems to have a > problem picking the appropriate overload: > > http://ci.infinispan.org/viewLog.html?buildId=52816&tab=buildResultsDiv&buildTypeId=Infinispan_MasterHotspotJdk9 :-/ Have you checked spec if this is a bug or if we have used unsupported behaviour? Anyway, until we figure out how to sort this out, we should keep the Streams API and Cache API in sync. I think that having this as compilation issue in user code at least forces user to define the lambda as serializable, it's not necessarily a bad thing (though annoying). > > Cheers > Dan > > > On Thu, Mar 23, 2017 at 10:42 AM, Radim Vansa <rva...@redhat.com> wrote: >> On 03/22/2017 08:46 PM, Katia Aresti wrote: >>> Hi all, >>> >>> Since Java 8, some new methods are available in the ConcurrentMap >>> interface: merge, compute, computeIfAbsent, computeIfPresent, forEach, >>> replaceAll. ConcurrentMap interface provides a default implementation. >>> >>> I'm working on https://issues.jboss.org/browse/ISPN-5728 >>> <https://issues.jboss.org/browse/ISPN-5728> in order to provide the >>> infinispan specific implementation. The issue here is that to make it >>> work, these lambdas must be Serializables, so actual code using these >>> methods and not passing serializables lambdas will break. >>> >>> I see two possibilities here, please fell free to suggest any other idea. >>> >>> 1) Override the default implementation and specify on the release that >>> all the lambdas must be serializables from now on ... ? >>> 2) Leave the implementation of the default methods as they are and >>> provide new methods implemented the infinispan way : >> To be consistent with Streams API, we should assume that the lambda is >> serializable (and fail as gracefully as we can if it's not and should >> be) and provide the SerializableX overload method to make the lambdas >> serializable when the lambda is used directly on Cache. I wouldn't leave >> the default implementation, because: >> >> 1) it's prone to user error, particularly during refactoring. Switching >> from functional to default implementation would introduce a regression >> in his app's performance >> 2) For local caches or local-mode operations, the lambda doesn't need to >> be serializable >> >> Radim >> >>> V compute(K key, Vcompute(K key, >>> SerializableBiFunction<?super K, ?super V, ?extends V> >>> remappingFunction) >>> >>> What do you think ? >>> >>> -- Katia >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Radim Vansa <rva...@redhat.com> >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
