FULL PRODUCT VERSION :
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Linux linux-notebook 2.6.11-co-colinux-20050720 #2 Thu Jul 28  customer :10:03 CEST 2005 i686 i686 i386 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
Some application of Java enums as constants require enum instances to be really constant over different JVM instances. This is currently not the case (as reported in Incident Review ID: 419641). The reason is the call to System.identityHashCode() by java.lang.Enum.hashCode(), whose result is JVM-instance-specific.

Another problem of java.lang.Enum.hashCode() is that it is 7 times slower than needed (see bug 6182955 for this).

One workaround would be to override hashCode() by the user. However, the current java.lang.Enum.hashCode() implementation is final. Being final barrs the user to workaround the deficiencies of the current java.lang.Enum.hashCode() implementation.


Thus, to meed the users needs, java.lang.Enum.hashCode() must not be final.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Workarounds are to not use Java enums at all, but to emulate enums by "normal" classes. However, it is not possible to use those "emulated constants" by "switch(EnumClass.constantObject)" statemens.
Posted Date : 2006-01-17 20:21:11.0

N/A

If the call to System.identityHashCode() (or super.hashCode()) is
really a problem, then we should fix that problem.

However, allowing users to override hashCode would imply that we
should also allow users to override equals.  This would very much
go against the design of enums and we will therefore not consider
making either hashCode nor equals non-final.

If a real problem with enum constants not being "really" constant
over different VM instances can be demonstrated, we can consider
that in a different bug report.
Posted Date : 2006-01-18 16:57:56.0

Using Sun Game Server (Project Darkstar) I bumped into this bug too.

http://www.projectdarkstar.com/index.php?option=com_smf&Itemid=&?topic=350.msg2475;topicseen#new

The following reproductes the bug:
[code]
class TestEnum {
    enum E {
        ONE
    }

    static class Foo {
    }

    public static void main(String args[]) {
        if (Math.random() < 0.5) {
            new Foo();
        }
        System.out.println("hashCode: " + E.ONE.hashCode());
    }
}
[/code]

emanuel@oak1:/tmp$ javac TestEnum.java 
emanuel@oak1:/tmp$ java TestEnum
hashCode: 8567361
emanuel@oak1:/tmp$ java TestEnum
hashCode: 9584176

I bumped into this using ehcache and spring-modules with auto cache key generation:
http://jira.springframework.org/browse/MOD-255

This is "really" a problem.  The hashCode for enum's should be stable across runs and it should be a reasonable hash value (have good distribution) which it also fails to offer.  Both equals and hashCode are quite reasonable for users to override.  It's essencially arrogant to imagine that users don't have valid reasons to change this.  Including correcting problems the system has introduced, like sability of the value and it's distribution.