Re: [infinispan-dev] ConcurrentMap new methods implementation
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.
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=buildResultsD...
Cheers
Dan
On Thu, Mar 23, 2017 at 10:42 AM, Radim Vansa <rvansa(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev