Question

There’s a piece of code that looks like this. The problem is that during bootup, 2 initialization takes place. (1) Some method does a reflection on ForumRepository & performs a newInstance() purely to invoke #setCacheEngine. (2) Another method following that invokes #start(). I am noticing that the hashCode of the #cache member variable is different sometimes in some weird scenarios. Since only 1 piece of code invokes #setCacheEngine, how can the hashCode change during runtime (I am assuming that a different instance will have a different hashCode). Is there a bug here somewhere ?

public class ForumRepository implements Cacheable
{
    private static CacheEngine cache;
    private static ForumRepository instance;

    public void setCacheEngine(CacheEngine engine) { cache = engine; }

    public synchronized static void start()
    {
        instance = new ForumRepository();
    }

    public synchronized static void addForum( ... )
    {
        cache.add( .. );
        System.out.println( cache.hashCode() );
        // snipped
    }

    public synchronized static void getForum( ... )
    {
        ... cache.get( .. );
        System.out.println( cache.hashCode() );
        // snipped
    }
}

The whole system is wired up & initialized in the init method of a servlet.
And the init() method looks like this conceptually:

// create an instance of the DefaultCacheEngine
cache = (CacheEngine)Class.forName( "com..DefaultCacheEngine" ).newInstance();
cache.init();

// init the ForumRepository's static member
Object o = Class.forName( "com.jforum....ForumRepository" ).newInstance();     
if( o instanceof Cacheable )
    ((Cacheable)o).setCacheEngine(cache);

// Now start the ForumRepository
ForumRepository.start();

UPDATE I didn’t write this code. It is taken from jforum

UPDATE 2 Solution found. I added a separate comment below describing the cause of the problem. Thanks to everyone.

Answer 1

You’re going to have to give WAY more information than this, but CacheEngine is probably a mutable data type, and worse, it may even be shared by others. Depending on how CacheEngine defines its hashCode(), this could very well lead to aForumRepository seeing various different hash codes from its cache.

It’s perfectly fine for the same object, if it’s mutable, to change its hashCode() over a period of time, as long as it’s done in a consistent manner (which is another topic altogether).

See also

• Object.hashCode() — make sure you understand the implications of the contract

---

On cache being static

More information has resurfaced, and we now know that the object in question, while mutable, does not @Override hashCode(). However, there seems to be a serious issue in design in making cache a static field of ForumRepository class, with a non-static “setter” setCacheEngine (which looks to be specified by Cacheable).

This means that there is only incarnation of cache, no matter how many ForumRepository instances are created! In a way, all instances of ForumRepository are “sharing” the same cache!

JLS 8.3.1.1 static Fields

If a field is declared static, there exists exactly one incarnation of the field, no matter how many instances (possibly zero) of the class may eventually be created. A static field, sometimes called a class variable, is incarnated when the class is initialized.

I think it’s important to step back right now and ask these questions:

• Does cache need to be static? Is this intended?
  • Should instances of ForumRepository have their own cache?
  • … or should they all “share” the same cache?
• How many instances of ForumRepository will be created?
  • Putting pros and cons of the design pattern aside, should ForumRepository be a singleton?
• How many times can setCacheEngine be called on a ForumRepository object?
  • Would it benefit from a defensive mechanism of throwing IllegalStateException if it’s called more than once?

The best recommendations would depend on the answers to the above questions. The third bullet point is something that is immediately actionable, and would reveal if setCacheEngine is getting invoked multiple times. Even if they’re only invoked once for each ForumRepository instance, it’s still effectively a multiple “set” in the current state of affairss, since there’s only one cache.

A static field with a non-static setter is a design decision that needs to be thoroughly reexamined.