In praise of Java 1.5 enums

[Roedy Green]

I tried flipping some code to use enums that used to use int.

All kinds of hard to proof read case statement methods collapsed to a
nice easy to extend list of constructor calls.

The big surprise came using the code. Almost nothing had to change but
a declaration from int to the AppCat -- the enum type. Everything
worked without a hitch first time.

The enum code is so much easier to maintain.


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

The big surprise came using the code. Almost nothing had to change but
a declaration from int to the AppCat -- the enum type. Everything
worked without a hitch first time.

You have a choice of flipping from static methods to enum instance
methods, but that is option, and a fairly mechanical.

The beauty comes when you add information to the constructor. It gets
rid of those gangly methods with strings of cases.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[farseer]

i have always written my own enum classes that maintain a hashtable to
ensure only one instance of any enum constant is instantiated. how
does the new classes help?

 

[Lasse Reichstein Nielsen]

i have always written my own enum classes that maintain a hashtable to
ensure only one instance of any enum constant is instantiated. how
does the new classes help?

It doesn't give you any new functionality, just a shorter syntax.
Behind the scene, enum classes are compiled into type-safe enum
classes.

/L

 

[Daniel Dyer]

It doesn't give you any new functionality, just a shorter syntax.
Behind the scene, enum classes are compiled into type-safe enum
classes.

/L

You can now use enum constants with case statements in switches, which you
couldn't previously.

Dan.

 

[Lasse Reichstein Nielsen]

You can now use enum constants with case statements in switches, which
you couldn't previously.

Sure, you just had to create a constant for each. Which is how enums
are compiled. It's just ugly . Something like this:
---
public abstract class SomeEnum {

public static final int FOO_CONSTANT = 0;
public static final int BAR_CONSTANT = 1;

public static final FOO = new SomeEnum(FOO_CONSTANT, "yadda");
public static final BAR = new SomeEnum(BAR_CONSTANT, "badda");

public abstract int getOrdinal();

private final int ordinal;
private final String text;
private SomeEnum(int ordinal, String text) {
this.ordinal = ordinal;
this.text = text;
}

public int getOrdinal() {
return ordinal;
}
}

 

[Dale King]

Sure, you just had to create a constant for each. Which is how enums
are compiled. It's just ugly . Something like this:

But that doesn't really classify as using the previous type-safe enum
pattern. That is using the type-safe enum pattern PLUS using the unsafe
enum pattern and maintaining a correspondance between the two manually.

 

[Roedy Green]

i have always written my own enum classes that maintain a hashtable to
ensure only one instance of any enum constant is instantiated. how
does the new classes help?

your implementation won't work in case statements or for loops.

Other programmers will have a tougher time understanding it, at least
once everyone gets familiar with Java enums.


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Scott Ellsworth]

your implementation won't work in case statements or for loops.

Other programmers will have a tougher time understanding it, at least
once everyone gets familiar with Java enums.

The new enums are one of the small list of reasons I want one of my
clients to finish their 1.5 validation. They would simplify a fair
amount of nasty code.

Scott

 

[Roedy Green]

The new enums are one of the small list of reasons I want one of my
clients to finish their 1.5 validation. They would simplify a fair
amount of nasty code.

A Zen master presented his student with a valuable box, with the
stipulation that it must always face east. The student took the box
and placed it in his room. However to place the box east, he had to
place the table against the wall on the opposite side of the room.
This meant he had to move the bed. This made getting in and out of the
room awkward, so he had to move the doorway in the wall. This caused a
structural weakness in the house which required…

Java 1.5 enums remind me of this story.

Once you add an enum or a generic to one class, you find yourself then
modify clients who use that class, then those who use those classes in
turn. I really have to think hard before I flip something.

Some stuff I definitely want to stay as old as possible for browser
compatibility.

It was gratifying to find that when I converted my code to enums I had
in fact made to type errors originally.

I am digging around now to find a way to make sure I never
inadvertently do a switch fall thru, as distinct from multiple case
labels which I do all the time.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Stefan Ram]

MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
structural weakness in the house which required?

The encoding "ISO-8859-1" does not contain a graphical
character at position 133 (decimal).

I know that, using "..." is against quality typographical
conventions, so you might use "\dots{}" and everyone will
understand. (I would use "\ldots{}" only in math mode.)

 

[Daniel Dyer]

I am digging around now to find a way to make sure I never
inadvertently do a switch fall thru, as distinct from multiple case
labels which I do all the time.

Compile with -Xlint:fallthrough to flag every fall-through as a warning
(this may not be so useful if there are some places where you
intentionally want to fall through.

Dan.

 

[Daniel Dyer]

Compile with -Xlint:fallthrough to flag every fall-through as a warning
(this may not be so useful if there are some places where you
intentionally want to fall through).

Never mind, I see from the other thread that you have already found it.

Dan.

 

[Tim Tyler]

But that doesn't really classify as using the previous type-safe enum
pattern. That is using the type-safe enum pattern PLUS using the unsafe
enum pattern and maintaining a correspondance between the two manually.

It was a bad example for illustrating the point - but the constants
*could* have been generated automatically as part of the factory
method that generated the enumerated constants.

As the OP said, this was ugly - and now it has been worked around.

 

[Tim Tyler]

Once you add an enum or a generic to one class, you find yourself then
modify clients who use that class, then those who use those classes in
turn. I really have to think hard before I flip something.

Some stuff I definitely want to stay as old as possible for browser
compatibility.

Most of the new stuff doesn't affect the bytecode - and so browser
compatibilty is not an issue - provided you configure the compiler
to output Java 1.1 bytecode.

I am digging around now to find a way to make sure I never
inadvertently do a switch fall thru, as distinct from multiple case
labels which I do all the time.

A *long* time ago, I wrote a Checkstyle check to do that.

AFAICR, the current version of Checkstyle can perform this task.

http://checkstyle.sourceforge.net/
http://eclipse-cs.sourceforge.net/

 

[Roedy Green]

Most of the new stuff doesn't affect the bytecode - and so browser
compatibilty is not an issue - provided you configure the compiler
to output Java 1.1 bytecode.

It won't let me! when I tried it said if you use -source 1.5 you
have to use -target 1.5. This came as a great shock. I thought the
whole point of doing generics and enums the way they were was so you
could say -target 1.3 and get away with doing type checking at compile
time for old Java Applets.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Tim Tyler]

It won't let me! when I tried it said if you use -source 1.5 you
have to use -target 1.5. This came as a great shock. I thought the
whole point of doing generics and enums the way they were was so you
could say -target 1.3 and get away with doing type checking at compile
time for old Java Applets.

After writing the above, I tried it too.

With both Eclipse's compiler and the 1.5 javac - it doesn't work.

It looks like something similar happened with version 1.4.
Perhaps "assert" at work - in the 1.4 case? I can't now remember what
the factor that made them shift the bytecode major version number at
that point was.

AFAICT, there's no terribly good reason why it shouldn't work - /if/
the compiler authors are prepared to put in the relevant work.

I would have thought loss of backwards compatibility with earlier VMs is
likely to be a compelling reason not to use new Java language features
for many.

 

[Dale King]

After writing the above, I tried it too.

With both Eclipse's compiler and the 1.5 javac - it doesn't work.

It looks like something similar happened with version 1.4.
Perhaps "assert" at work - in the 1.4 case? I can't now remember what
the factor that made them shift the bytecode major version number at
that point was.

AFAICT, there's no terribly good reason why it shouldn't work - /if/
the compiler authors are prepared to put in the relevant work.

I would have thought loss of backwards compatibility with earlier VMs is
likely to be a compelling reason not to use new Java language features
for many.

I hear you! I had the same reaction. I too thought that the reason that
they did generics the way they did was to have that backward
compatibility (Sun oddly calls this forward compatibility). I thought it
was going to be like the way nested classes were introduced. Nested
classes were introduced in 1.1, but the generated classes could run in
earlier VM's. But such was never their intention. But then why did we
end up with the lousy implementation of generics?

I have been told that there is an undocumented way to do it. You specify
jsr14 as the target. And if I don't mention it someone else will mention
retroweaver which is an open source tool to do it (but which is not
really a solution in my opinion).

 

[pkriens]

Why do you call "Forward Compatibility" odd?

Backward Compatibility is when you can run old code on new VMs. So how
would you call new code that can run on old VMs? This is clearly
another case, and the term forward compatibility seems to make sense.

Kind regards,


Peter Kriens

 

[Dale King]

Why do you call "Forward Compatibility" odd?

Backward Compatibility is when you can run old code on new VMs. So how
would you call new code that can run on old VMs? This is clearly
another case, and the term forward compatibility seems to make sense.

Which sure seems backward to me. I think it is a matter of which
direction you consider backward and foreward.

It seems to me that the ability to take new features to older software
is going backwards and having old software to work in the newest sytem
is going forward.

Incidentally, Wikipedia agrees with Sun on its definitions.