Interface FunctionalMap<K,V>

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
@Experimental public interface FunctionalMap<K,V>
Top level functional map interface offering common functionality for the read-only, read-write, and write-only operations that can be run against a functional map asynchronously.

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. 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 pull-style API for working with multiple results. Although push-style 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 pull-style 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

  • Method Details

    • create

      static <K,V> FunctionalMap<K,V> create(AdvancedCache<K,V> cache)
      Create a FunctionalMap which wraps the supplied AdvancedCache
      Type Parameters:
      K - the key type
      V - the value type
      Parameters:
      cache - the AdvancedCache to wrap
      Returns:
      an instance of FunctionalMap

    • toReadWriteMap

      FunctionalMap.ReadWriteMap<K,V> toReadWriteMap()
      Returns a ReadWriteMap, a FunctionalMap with semantics specific to read/write use-cases

    • toReadOnlyMap

      FunctionalMap.ReadOnlyMap<K,V> toReadOnlyMap()
      Returns a ReadOnlyMap, a FunctionalMap with semantics specific to read-only use-cases

    • toWriteOnlyMap

      FunctionalMap.WriteOnlyMap<K,V> toWriteOnlyMap()
      Returns a WriteOnlyMap, a FunctionalMap with semantics specific to write-only use-cases

    • withParams

      FunctionalMap<K,V> withParams(Param<?>... ps)
      Tweak functional map executions providing Param 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

      Cache<K,V> cache()