aspose file tools*
The moose likes Beginning Java and the fly likes Benefits of enum types Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Benefits of enum types" Watch "Benefits of enum types" New topic
Author

Benefits of enum types

Pho Tek
Ranch Hand

Joined: Nov 05, 2000
Posts: 761

Currently sprinkled all over a codebase I'm maintaining are enumerations written as (an example):


Rewriting this using JDK5's enum native support would introduce more LOCs.
How can I convince the other developers that it is worth the effort to convert ? Thanks

Regards,

Pho
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Pho Tek:
...How can I convince the other developers that it is worth the effort to convert ? ...

Are you convinced? Why or why not?

(I assume "LOC" means lines of code.)


"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Pho Tek
Ranch Hand

Joined: Nov 05, 2000
Posts: 761

LOC = Lines of code. Yes

I am convinced about its usefullness esp. with regard to type safety.

Note that google discourages the use of enums on their Android platform.
http://code.google.com/android/toolbox/performance.html#avoid_enums

Regards,

Pho
[ November 24, 2008: Message edited by: Pho Tek ]
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19670
    
  18

How would this introduce more lines of code?

Compare:


Looks like 6 lines in both examples. And in calling code I also can't see any difference, since both support the same language constructs, including switch statements.

I see added potential with enums. It's the power of an object combined with the ease of an int. And you can't use a value like 481 where you expect only 0-1. The only "odd" value is null.
In fact, I've written my own Enum class for projects in Java 1.4 that mimics enum in almost every thinkable way. The only thing I haven't been able to get to work is switch statements.


As for the Google Android link, that is for embedded systems where both available size and processor speed are a lot less than those of the usual machine used by users. So unless performance and size is really an issue, I'd go for enums every day of the week.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Tom Johnson
Ranch Hand

Joined: May 11, 2005
Posts: 142
Hey Rob,
We use the same enum pattern pre-5.0 java and use a method for the switch statement issue....
[ November 24, 2008: Message edited by: Tom Johnson ]

<a href="http://faq.javaranch.com/java/UseCodeTags" target="_blank" rel="nofollow">Use Code Tags!!</a>
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19670
    
  18

But then you still have to hard-code the ordinals as constants (public static final int), something I do not like. Ideally it would work exactly the same - the class fills in the name and ordinal for you. What if you want to add an enumerated value between two existing onces? With Java 1.5's enum, the ordinals will get shifted. That's something I'd like too.

In fact I have something like that but it has one flaw - it depends on Class.getDeclaredFields returning fields in the declared order. And that's an assumption that cannot be made. It works for now but it's not guaranteed to work.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19670
    
  18

Right, I've solved that problem for the greater part.

During object creating, I count the number of public static final fields of the same type that are not null. That's going to be the next ordinal. During the setting of the first object, it is created first. There are no non-null fields so the ordinal will be 0. It is then set, and the number of non-null fields will become one. And so on.

As for the name, in the name() method I loop through the fields again, and for all non-null fields without a name the name is set to be the same as the field's name. That should be called only during the first call to name() for all objects combined, unless of course it is called in a constructor.


This approach can still mix up the ordinal order but unfortunately that's something that can't be prevented. I think I'll give developers the chance to set them manually too.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Benefits of enum types