On Sat, Jun 10, 2017 at 12:56 AM Radim Vansa <rvansa(a)redhat.com> wrote:
Hi guys,
when the functional API has been outline, the interfaces were put into
infinispan-commons to make it possible to share these between remote
clients and embedded use case. However, it seems that reusing this as-is
impossible or at least impractical as we cannot send the lambdas in a
language neutral way. In the future, we may implement a way to share
functions between client and a server but that will most likely result
in an interface accepting something else than Function<ReadWriteEntry,
R>. Also, it's rather weird to have two EntryVersion interfaces.
Therefore I suggest moving org.infinispan.commons.api.functional to
infinispan-core, package org.infinispan.api.functional
You might say that the server-side code would use the interfaces, but
once it's running on server, it should depend on core (or core-api) -
commons is what is shared with the client, and if the client will in
future register a new function on the server, the user code should
depend on core-api as well (client-hotrod itself does not have to).
If you wonder what led me to this is that I've tried to add
SerializableFunction overloads to the FunctionalMap and found out that
SerializableFunction et all are only in infinispan-core (for good).
We could move these into commons in a major version if we need to as well.
I never thought about using them in the client code as we never planned on
supporting serialized lambdas there, but if it makes other things easier I
am for it.
Also there is nothing stopping us from having these in commons right now,
there is nothing special about the interfaces, they can just be copied over.
Please let me know if you have objections/if there something I have missed.
Radim
--
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