http://jira.jboss.com/jira/browse/JBCACHE-941

From the issue:

The java.util.Collections utility class supplies useful methods for dealing with legacy interfaces and wrapping collection classes for concurrency, type safety, read-only, etc.

In a simiilar vein, I wrote a "Caches" class that returns java.util.Map instances for a Node, which allow data to be modified through the standard Map interface.

This I expect to be extremely useful for allowing uses to integrate their existing application with JBoss Cache, and will eliminate some of the confusion of using a new API and they can use the API they know best. Users also often demand an API which is "generic" so that their code is not tied to a particular vendor.

There are basically two methods in Caches, one looks like this:

Cache cache = DefaultCacheFactory.getInstance().createCache();
Map m = Caches.asMap(cache);
m.put("foo", "bar");

The API and examples explain themselves.

"Caches" could also include other useful methods for printing or reporting.

Note that this functionality could be considered duplicated from PojoCache...

/**
 * Returns a {@link Map}, where map keys are named children of the given Node,
 * and values are kept under a single key for this node.
 * The map may be safely concurrently modified through this Map or externally,
 * and its contents reflect the cache state and
 * existing data of the Node.
 * This means that {@link ConcurrentModificationException} is never thrown
 * and all methods are thread safe.
 * <p/>
 * The map is not serializable.
 * <p/>
 * Usage note: As a single node is used for every key, it is most efficient to store
 * data for a single entity (e.g. Person) in a single object.
 * <p/>
 * Also, when using a {@link CacheLoader} for storage, keys used must be valid as
 * part of the {@link Fqn} used in calls. Generally speaking, simple string values are
 * preferred.
 */