A native enumeration type (i.e. the ability to
reference a named constant that you don't care 
what the value is - eg: RED,BLUE,GREEN) is very 
missing in the core language definition of Java.

Why isn't there one - and are there plans to add 
it?
(Review ID: 20067)
======================================================================

final static constants (yech!)
======================================================================

There aren't any plans to add an enum type to the language.  I am assigning this to Dave so he can comment further, if he'd like, or just close this.

  xxxxx@xxxxx   1997-11-18

Interfaces that define static final constants go a long way towards to
functionality of enums; what they miss is the type-safety.  Enums could
in fact be useful to the extent that they improve readability and safety.
At this time there are no plans to add enums to the language.  Static
final constants may be suboptimal, but they are a sufficiently workable
solution for the moment; they aren't a big enough win to warrant changing
the language at this point.

  xxxxx@xxxxx   1997-12-04

We'll be reviewing this issue for future releases.

  xxxxx@xxxxx   2001-02-08

Interfaces that define static final constants may
miss type-safety, but what they really miss is 
convenience, and avoidance of duplication. I love
using enumerated variables in C++, and (unlike
most of the powerful features of C++) they don't
bring a lot of baggage to the language.
Although the convenience of enums is a bug plus,
I especially like the way enums avoid duplication
problems. This is a good example of using a 
language feature to eliminate a class of bugs.
Their exclusion from java is a (rare) step 
backwards.
Incidentally, interfaces with constants don't
really give us the functionality of enums, they
give us the functionality of include files. (Which
is great.) I still miss enums when I work with 
java.

P.S.  Why is this closed?  I want to vote for it!  :-)

Convenience is certainly a factor, but type safety is far more important.  I
find it very hard to accept that type safety isn't a big enough win to warrant
changing the language.  Java provides type safety just about everywhere else -
lack of enum is just plain inconsistent.
This sort of feature should be able to be introduced with minimal impact -
surely it would not affect the VM...??

I want to vote for it too

Not having enums is intolerable.
My comments on functions that take "int"s now have
to list all the acceptable values.
As already mentioned, enums provide compile-time
type checking - checking for correct values at 
runtime brings an overhead with it, and also 
allows only two choices - either you convert the
wrong value to the "closest" acceptable value,
so doing something which may have been entirely 
undesired by the person who used the "int", or
you throw an exception - absolutely unacceptable,
for what is basically a kind of typo!
Secondly, enums make the meaning of a function
much clearer (especially if the return is an enum).
Shame on you, Sun, for not adding enums!

james gosling's $.02 can be found at
http://www.javaworld.com/javaworld/jw-06-1998/jw-06-letters.html

One uses classes to get type-safe enumeration of
values in an object-oriented programming language,
not ints and not C-like enums.

I always thought one of the big advantages of JAVA is type safty. Why not in
this case ?

I want to vote for this, also.  The performance of Java is slow enough without
having to declare heavy-weight classes just to return an enumerated value.  

The lack of enumerated types is truly infuriating. I think it rather folish to have closed the voting on it, too.

Here is a potential solution:

public class Car
{
      protected Car() {}
      public static final Car FORD=new Car();
      public static final Car VW=new Car();
      public static final Car SAAB=new Car();
}

...apparently this works. I have yet to test it fully.
Source: http://www.javaworld.com/javatips/jw-javatip27.html

It is very unfortunate that they refuse to fix this. The 
official line is that you should create a class with a 
private constructor and public static member instances.

Enums (as implemented in C++) would be much easier to use. 
Without them everyone (even the Sun programmers) ends up 
using int constants, which makes the code more fragile.

Does anyone in Sun read these?  Please reopen this bug!

Please review and add this facility. Almost everyone I know
considers this a flaw in the language definition and would
like to see enumeration constants. How hard cane it be to
do?

I can't believe there is no enum support.  As it is, it's a very clumsy way to emulate an enum.

Using static final int constants is a ridiculous 
alternative to using enum types. A method setDay(int) is 
simply not logical (it must be setDay(dayOfWeek), where 
dayOfWeek is {monday,...,sunday}). Furthermore this way a 
static typecheck is not possible, so reliability suffers 
significantly. The statement '...they aren't a big enough 
win' states quite a portion of ignorance of developing 
reliable software systems; for some C hacking int constants 
might actually be enough. And finally, defining classes 
with these constants and get/set method induces quite a lot 
of unnecessary overhead to the programmer, which itselfs 
might induce bugs.

Classes like this:

public class Car
{
      protected Car() {}
      public static final Car FORD=new Car();
      public static final Car VW=new Car();
      public static final Car SAAB=new Car();
}

solve many problems, but I want to be able to use enumerations in switch statements. I can't say

public void doSomething(Car theCar)
{
  switch (theCar)
  {
      ...

because the switch requires an integer. And if I give an integer value to each enumaration, I can't say

    ...
    case FORD.intValue:

because this requires a constant. It doesn't even work if I make intValue final. I want integral enumerations 
with type safety.