I use them for constants that don't need a value, as they should be used for.

EDIT: For example, I'm working on a text-based interactive fiction for school, and I used Enums for NORTH, SOUTH, EAST, and WEST.

Yeah, I have started to do this too, so there are less potential errors.I mean if you have Direction myDirection = NORTH, its safer than just using an int, because someone could just mix it up and do like myDirection = 7;But some of my team hate enums, so I was just interested in the general consensus.

I don't like enums in Java, because I think they missed the point. I just want a numerical constant, man. Java's is basically just a class, it's too overly complicated. I usually just use constant integers or strings.

In the Hotspot JVM (not the bytecode, so this is implementation dependent) it's all turned into ints, and if you have more than 32 enum values, it's (obviously) converted to a long. Beyond that, it uses byte[]. This is done to be able to transform the functionality of EnumSet to binary operators.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

In the Hotspot JVM (not the bytecode, so this is implementation dependent) it's all turned into ints, and if you have more than 32 enum values, it's (obviously) converted to a long. Beyond that, it uses byte[]. This is done to be able to transform the functionality of EnumSet to binary operators.

Dang. I feel for you, man. Having your ints shrink to 5 bits must be harsh... Even worse, your bytes are 1.25 bits each, and that's before rounding errors!...Why can you only fit 32 different values in an int? Does only use powers of 2?

I don't like enums in Java, because I think they missed the point. I just want a numerical constant, man.

The whole point of enums is that they're NOT numerical constants and that each set of enums is a distinct type from each other. This is why I can't set my direction to COLOR_RED or my color to NORTH. And if you're going to introduce distinct types in Java, you're going to do it with classes, unless you're keen on creating a parallel type system that only works for enums.

I use them mainly to eliminate invalid values when only a (very) limited range of values is expected. Sure, I agree that they are a little bit too powerful, but I'd rather have them too powerful than too weak, as long as that doesn't come with a too big performance hit of course.

Even before I started using dynamic and functional languages more heavily, I always felt there was a lot of cruft around enums. But being able to just do 'blah', 'Blah', or ':blah' for denoting an atom/symbol, is so much easier then the whole 'EnumClass::FOO_BAR' + it's declaration.

Another case i use enum is for avoid a maximum of boolean parameters. Why ? because they are too low significant when i read a call usage and i never remember what this boolean is for when reading code.A small enum in theses cases make the code more readable and more extendable if in a long time the 2-values parameters (boolean) became a 2+ values...

Another case i use it is when i need to store values for a serie of predefined constants. In this case, i use an EnumMap that is really efficient.

I've used enums from time to time, but mostly find them too verbose, and too powerful.

I'm surprised by the number of people who seem to have this opinion on this thread. Too verbose? How? Using them at their simplest surely enums are less verbose, because you don't have to assign them a value at creation or check for invalid values in use. And as for too powerful, it's not like you have to use it or worry about it, but at times it's useful. Eg. I sometimes use fields to map Java enums to native enums in a type safe way, such as here

The elegant bit is how this maps down underneath to (practically) identical code. And you get type-safety, both for individual flags, as well as a separation between a set of flags and the flags themselves.

Dang. I feel for you, man. Having your ints shrink to 5 bits must be harsh... Even worse, your bytes are 1.25 bits each, and that's before rounding errors!...Why can you only fit 32 different values in an int? Does only use powers of 2?

Dang, I think I heard the whooosh as you missed the point! Bitsets means one bit per value - so yes, in powers of 2.

In the Hotspot JVM (not the bytecode, so this is implementation dependent) it's all turned into ints, and if you have more than 32 enum values, it's (obviously) converted to a long. Beyond that, it uses byte[]. This is done to be able to transform the functionality of EnumSet to binary operators.

Dang. I feel for you, man. Having your ints shrink to 5 bits must be harsh... Even worse, your bytes are 1.25 bits each, and that's before rounding errors!...Why can you only fit 32 different values in an int? Does only use powers of 2?

Maybe take your condescending attitude and give it some thought first. I even explained it in that very message.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Any elegant solutions to use an enum and still be able to do the equivalent of "CENTER | LEFT"?

CENTER_LEFT. Or as explained above, a Set<Direction> containing CENTER and LEFT, which there's some library support for already.

The point of enums is that they fully enumerate the possible values, and that no new values of that type can be synthesized. If you need them to act like bits, you don't really have an enum. Now for compatibility's sake, such as with OpenGL's many many constants, you can assign values to the enums, but for sake of your particular example, it wouldn't gain you any benefit in terms of syntax.

The elegant bit is how this maps down underneath to (practically) identical code. And you get type-safety, both for individual flags, as well as a separation between a set of flags and the flags themselves.

The elegant bit is how this maps down underneath to (practically) identical code. And you get type-safety, both for individual flags, as well as a separation between a set of flags and the flags themselves.

Hmm. It's ok, if a bit clunky. Does this allocate? Seems to.

If it's all converted to ints in the JVM, why would it allocate? (it might allocate in bytecode, but that's not the point)

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

In the Hotspot JVM (not the bytecode, so this is implementation dependent) it's all turned into ints, and if you have more than 32 enum values, it's (obviously) converted to a long. Beyond that, it uses byte[]. This is done to be able to transform the functionality of EnumSet to binary operators.

Dang. I feel for you, man. Having your ints shrink to 5 bits must be harsh... Even worse, your bytes are 1.25 bits each, and that's before rounding errors!...Why can you only fit 32 different values in an int? Does only use powers of 2?

Maybe take your condescending attitude and give it some thought first. I even explained it in that very message.

Ehm... why? As said, maybe in bytecode, but not in HotSpot... it's just an int.

There is more to an EnumSet than an int, such as the Set interface. What may be the case is after inlining that the relevant membership tests become int operations. but HotSpot doesn't do anything without it being bytecode first. JIT does a lot, but it's not magic

Quote

If that's directed at me... I'm just answering a question, explaining what happens underneath.

No, it's directed at people who are actually fretting about Enums having more overhead than ints.

I've used enums from time to time, but mostly find them too verbose, and too powerful.

I'm surprised by the number of people who seem to have this opinion on this thread. Too verbose? How? Using them at their simplest surely enums are less verbose, because you don't have to assign them a value at creation or check for invalid values in use. And as for too powerful, it's not like you have to use it or worry about it, but at times it's useful. Eg. I sometimes use fields to map Java enums to native enums in a type safe way, such as here

The main issue I have is that if you want to use enums heavily, then it requires _lots_ of enum declarations. That is a scenario where symbols/atoms work much better, because you are essentially declaring the enums within their usage, making the code much more terse.

You could then also add guards or pattern matching, for automatic verifying parameters. These would then be verified using type inference, or at runtime. But I don't think Java could really take guards and symbols, or should really get them. Both would be moving away from Java's static type system, which wouldn't fit the philosophy of the language.

So I think Java enums work well for Java, but aren't so great when compared to what you can do in other languages.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org