and inability to reuse existing code, developed for unrelated
applications, that does one, but not both, of the jobs.

The following would need a remove method added, but it should be obvious
how to do that.

/*
 * Created on Aug 14, 2004
 */
package utilities;

import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;

/**
 * Utility class for counting instances of equal objects.
 */
public class Counter {

  private Map<Object,Count> data = new HashMap<Object,Count>();

  /**
   * Increment by one the count associated with a specified
   * key.
   * @param key
   */
  public void increment(Object key) {
    Count count = data.get(key);
    if (count == null) {
      count = new Count();
      data.put(key, count);
    }
    count.increment();
  }

  /**
   * Get the count associated with a specified key.
   * @param key The key whose count is required.
   * @return The number of times increment has been called with
   * a key equal to this one.
   */
  public int get(Object key) {
    Count count = data.get(key);
    if (count == null) {
      return 0;
    } else {
      return count.get();
    }
  }

  /**
   * Get number of unique counted objects
   *
   * @return Number of key objects for which increment
   * has been called. Equal objects are only counted once.
   */
  public int size() {
    return data.size();
  }

  /**
   * Get all the unique counted objects
   * @return A set containing a refence to the counted objects.
   */
  public Set getKeys() {
    return Collections.unmodifiableSet(data.keySet());
  }

  private static class Count {
    private int val = 0;

    private void increment() {
      val++;
    }

    private int get() {
      return val;
    }
  }

}

Honestly, I don't understand your points:

Um, where is this code complicated?

The requirement that the cache class must count hits automatically means
that two unrelated things happen in one method: lookup and counting.  Or
did you mean something else?

This is completely encapsulated inside the Cache class.  And I also do
not see how this is obscure.

Maybe I'm too tired right now to get your point.  I'd appreciate it if
you elaborate it a bit more.  Or you illustrate your point with another
solution so everyone can compare both of them.

Kind regards

    robert

May be. I did not yet do any real memory consumption test. I probably
will do really soon. But until then I think, every object counts - at
least for objects in the global cache (that will go into old-gen) and
for numbers of objects growing with the size of the cache.

I'm also a bit annoyed, because the functionality I need is neither
difficult to implement (for the JCF) nor ugly design. My way of storing
the hits counter may be ugly, but providing the getKey functionality is
not. It's a one-line-method, and it has just been forgotten.

Not that I want to do any JCF-bashing. In fact I think, JCF is one of
the most well designed libraries ever written for Java. And Java is one
of the best (general purpose) programming languages ever implemented.

I really like static type safety. Within my framework, its a
compile-time error to assign a double value to a persistent field of
type string. Its also a compile-time error to compare a string field to
a double value (or a double field) within a database query. Same with
using the "like" operator on a double field. And of course, queries for
customer objects return a Collection<Customer>. Removing a persistent
field or class from the schema gives you compile-time errors, whereever
you used it (including database queries of course, not just
getters/setters). Renaming a persistent field or class using a modern
Java IDE really renames all references to that field, including those
in queries. No more "column not found"-SQLExceptions. I *hate* writing
database queries in some plain text language.

Second I don't like writing XML (or any other external, non-java)
description of the persistent schema. Within COPE (did I mention the
name of the framework already :-) ), everything is specified within
your Java source code. Everything. Persistent classes, fields,
constraints, queries.

And I want support for migrating the database to new versions of the
application without loss of data. For instance, if you add a new
persistent field to the schema you must not forget to add a new column
to the database table. For COPE there is a helper application telling
you which column (or table or constraint) is missing (or not used any
longer) and lets you create (drop) it with a single click. I really
missed this in my projects, because it's another typical source of that
"column not found"-SQLExceptions.

And I don't want to waste my time remembering, which column type can
store a string up to 400 characters most efficiently with that
particular database I'm using right now. Was it "varchar(400)" or
"varchar2(400)" or "text" or "tinytext" or just "string" ? Grmpf. COPE
does that for you.

Ooops. Got a bit lengthy :-) .
And of course the cache will be the most effifcient on earth when it's
ready, but it's not yet. :-)

There is also a website, with some explanation:

http://cope.sourceforge.net/

Thanks a lot. I just registered.

Best regards,
Ralf.