Interface FunctionalMap<K,V>
- All Superinterfaces:
AutoCloseable
- All Known Subinterfaces:
FunctionalMap.ReadOnlyMap<K,
,V> FunctionalMap.ReadWriteMap<K,
,V> FunctionalMap.WriteOnlyMap<K,
V>
- All Known Implementing Classes:
FunctionalMapImpl
,ReadOnlyMapImpl
,ReadWriteMapImpl
,SimpleReadOnlyMapImpl
,SimpleReadWriteMapImpl
,SimpleWriteOnlyMapImpl
,WriteOnlyMapImpl
Lambdas passed in as parameters to functional map methods define the type of operation that is executed, but since lambdas are transparent to the internal logic, it was decided to separate the API into three types of operation: read-only, write-only, and read-write. This separation helps the user understand the group of functions and their possibilities.
This conscious decision to separate read-only, write-only and read-write interfaces helps type safety. So, if a user gets a read-only map, it can't write to it by mistake since no such APIs are exposed. The same happens with write-only maps, the user can only write and cannot make the mistake of reading from the entry view because read operations are not exposed.
Lambdas passed in to read-write and write-only operations, when
running in a cluster, must be marshallable. One option to do so is to
mark them as being Serializable
but this is expensive
in terms of payload size. Alternatively, you can provide an Infinispan
Externalizer
for it which
drastically reduces the payload size. Marshallable lambdas for some of
the most popular lambda functions used by ConcurrentMap
are
available via the MarshallableFunctions
helper class.
Being an asynchronous API, all methods that return a single result,
return a CompletableFuture
which wraps the result. To avoid
blocking, it offers the possibility to receive callbacks when the
CompletableFuture
has completed, or it can be chained or composes
with other CompletableFuture
instances.
For those operations that return multiple results, the API returns
instances of a Traversable
interface which offers a lazy pullstyle
API for working with multiple results. Although pushstyle interfaces for
handling multiple results, such as RxJava, are fully asynchronous, they're
harder to use from a user’s perspective. Traversable
, being a lazy
pullstyle API, can still be asynchronous underneath since the user can
decide to work on the Traversable
at a later stage, and the
implementation itself can decide when to compute those results.
- Since:
- 8.0
-
Nested Class Summary
Modifier and TypeInterfaceDescriptionstatic interface
Exposes read-only operations that can be executed against the functional map.static interface
Exposes read-write operations that can be executed against the functional map.static interface
Exposes write-only operations that can be executed against the functional map. -
Method Summary
Modifier and TypeMethodDescriptioncache()
getName()
Functional map's name.Functional map's status.default boolean
Tells if the underlying cache is using encoding or notwithParams
(Param<?>... ps) Tweak functional map executions providingParam
instances.Methods inherited from interface java.lang.AutoCloseable
close
-
Method Details
-
withParams
Tweak functional map executions providingParam
instances. -
getName
String getName()Functional map's name. -
getStatus
ComponentStatus getStatus()Functional map's status. -
isEncoded
default boolean isEncoded()Tells if the underlying cache is using encoding or not- Returns:
- true if the underlying cache is encoded
-
cache
-