January 11, 2006

Ok, geek time

I just read the niftiest new thing I've seen in a while. I've hated certain aspects of Java pretty much since it came out in the mid-90s, but for several years now we've known the feature list of Java 1.5, and it addressed my complaints, and threw in a few other nice things that I hadn't complained about, but appreciate the improvement.

So for maybe three years now, I've been raving about Java 1.5 despite not actually being able to write anything in it—it's been out quite a while now, but not on all platforms, and general adoption has been slow in some areas. Anyway, in helping a student decide how to implement a certain aspect of his project, I wanted to check out how Java 1.5 implemented the enumerated types I'd heard about.

They're so cool!

The basic enumerated type has been around for decades: in Pascal, for instance, you could say

type Month = (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec);
var m: Month;
m := May;
and this was judged to be cleaner than saying "m := 5" because you couldn't mistake a Month for a Day or a Suit or anything else. However, the identifier May was still really only a fancy name for the number 5 (or perhaps 4); there wasn't anything you got out of it other than readability and type safety. In C, it was really nothing more than a fancy name for a number—you didn't even get type safety out of the bargain.

So I figured Java's enums were out of this mould, probably more like Pascal than C but still just slightly fancy numbers. No, no, no. Java enums are quite a high-level construct, in fact; while you can treat them like Pascal enums, they can also carry data and behaviours just like any other object. Because in Java, an "enumerated type" is just a class whose instances are all known at compile time. So if you have a limited list of things, like notes on a scale or planets in a solar system or items in a pull-down menu, regardless of how complex those objects are, you get to use an enumerated type.

And a few things come for free when you define an enum, like values() and toString(), which along with the "for-each" loop (another grand new construct in Java 1.5) lets you write stuff like

  public enum Suit { SPADES, HEARTS, DIAMONDS, CLUBS }
  for (Suit s: Suit.values() ) {
    System.out.println (s);
and it will print out the names of each suit, in order. Nifty, eh?

The Joys of Finnish:
"Kokko, Kokoon koko kokko." ("Kokko, gather together the whole bonfire.")
"Kokoko kokko?" ("The whole bonfire?")
"Koko kokko, Kokko." ("The whole bonfire, Kokko.") --Eric Dahlman

Posted by blahedo at 5:19pm on 11 Jan 2006
When were enums added to the specification? I either don't remember them or was unable to figure them out, because I so would have used that in the last Java project I did. Posted by Kelly Martin at 7:48pm on 11 Jan 2006
Well, I don't know when they were added, but they were certainly in there as of 1.5. Follow the link above for the spec description of them. Posted by blahedo at 8:13pm on 11 Jan 2006
Yep. Enums are part of the Java SE 5 spec. What's that you say? Don't I mean 1.5? Well, actually no. The 1.x notation is still around, but Sun did it's version magic and now: J2SE 1.5.x => Java SE 5 (Not 5.0) and JSEE 1.5.x => Java EE 5. All hail our less precise version lords. Posted by Michael McLawhorn at 9:24am on 16 Jan 2006

My goodness. You remember your Pascal? I haven't touched it since freshman year. Well nigh 19 years ago.

Heh. I think I am slipping into "old fart" mode. Using phrases like "well nigh".

Posted by ansible at 9:49am on 16 Jan 2006
Of course not! I had to google for the appropriate Pascal syntax. :) Posted by blahedo at 11:54pm on 16 Jan 2006
So Java's enumerated types are, indeed, pretty cool. Nonetheless, given the choice between Java and C#, I'll take C# almost every time. The primary, and most important reason: properties. Yeah, JavaBeans have a method naming convention for properties, but C# (or, rather, the .NET CLR) has reflectable properties. Want to know what properties an object or class has? Ask for its properties. No futzing around with asking for methods and checking to see which ones are named get* or set* and deriving a name and a type from them. If you are going to pay for a rich runtime, make sure the runtime actually does enough. Ugh. Oh, and C# has C-style enumerations, with a little bit of code around them for converting between numerical values and strings and such. Posted by Greg at 9:14am on 18 Jan 2006
Mike: They've been dual-versioned for a while now, but the developer version number is still 1.5.0 as described in this document, where they basically say, "yeah, we keep trying to change the major version number for marketing reasons, but the people who know what they're doing won't go for that, so we're using the old numbering too."

Greg: Is any of that really a benefit to C#? I think all the stuff you describe is from .NET (and you allude to this fact). And, quite independently of the fact that C# was developed by Microsoft, I believe it still remains the case that to seriously use it you're still locked in to the Microsoft hegemony. So, no.

Posted by blahedo at 1:46am on 19 Jan 2006
Yes, it is more from .NET than from C# itself (though the C# property syntax is convenient). That's actually better, though, because the .NET CLR and IL and a small section of the base API (including basic types and reflection stuff) are an ECMA standard and are headed toward being an ISO standard. Sure, Microsoft developed it, and they ship gobs of extra libraries that are not standardized, but the stuff I'm talking about is part of the standard. The Mono project already implements the stuff I'm talking about. Posted by Greg at 11:28am on 19 Jan 2006
Post a comment

Write this number out in numeral form: four hundred and thirty two

Remember personal info?

Valid XHTML 1.0!