JavaOne: Day Two

Still having problems with my wireless, after two BIOS updates and a driver update. I'm back to hardwired network in the hotel room. Thanks to all who added more information at the end of the post on yesterday.

Today was a good day. I skipped the rather skimpy conference continental breakfast (I've really been spoiled by TechEd), got something at the hotel, and headed over for the keynote.

Scott McNealy is a very good speaker. He comes across as folksy and funny. He spent some time talking about the Microsoft and Sun agreement, and explaining why Sun did it. It's very strange for Scott to be saying nice things about MS - I guess it's good that Larry hasn't changed.

He talked a little about the press that Sun has been getting and their financial situation. This was primarily for the analysts and press (who got to stay the whole time today).

Notable events:

A game demo using Java as a script language in a first-person shooter. That's labelled as a “game using Java technology”, though I didn't think it was much of an accomplishment, as that can be said of many languages (Python, Perl, Tcl, but not - to my knowledge - about C#)

The second was a game engine written in Java, which looked okay but a bit jerky in demo. Without knowing what kind of rendering it was doing, it's hard to know how impressed to be, but details were not forthcoming.

The third was an unveiling of the Phantom by Infinium labs, where they said they would be shipping J2SE on the machine. Beyond that, and pulling a drape off a mockup of the machine, that was about it. It's obviously not working hardware yet, and the Java part really seems to be an “also available“ item.

Taming the Tiger 5.0 Talk

This was a talk that covered most of the language features not covered yesterday. The ordering of the talks was unfortunate, but I've been there at some of our conferences.

As others noted in comments to my last post, if you use 1.5 features, you have to run on a 1.5 VM. So apparently the goal was to keep VM changes to a minimum rather than having no changes. I can understand not wanting to require all JVM writers to have to make big changes to support generics.

There was lots of talk about foreach, and “gushing“ would not be going to far (“Once you start using foreach, it's addictive“. I agree that it's a great feature.

I got my first introduction to the new Java enum support. They went for what I would call a “full“ implementation, in that they're class-based rather than being based on integers (my guess is that part of this is also to keep JVM changes to a minimum).

Java enums have some “interesting“ capabilities. For example, you can write:

public enum Operation {

            PLUS {double eval(double x, double y) {return x + y;}},

            MINUS {double eval(double x, double y) {return x - y;}},

            TIMES {double eval(double x, double y) {return x * y;}},

            DIVIDE {double eval(double x, double y) {return x / y;}},


            abstract double eval(double x, double y);



and then write:


for (Operation op: Operation.values())

            double results = op.eval(x, y);

That, I submit, is a really weird thing to do, and I don't understand the utility of being able to do this as part of an enumerated type. Am I missing something here?

Static import is a feature to allow you to write something like “Sin“ rather than “Math.Sin“. I don't think this is good for a language to do.

More Programming Puzzlers

A very interesting and well-presented, in which 8 programming puzzlers were presented by two presenters (alternatively). They were all console apps, and the puzzle for the audience is to figure out what the apps print. I was slightly hampered by my lack of Java library knowledge, but I got 2 of the 8.


I’m happy to say that 3 and perhaps 4 of the puzzlers aren’t possible in C# because we have more stringent rules. A particular one that almost the entire crowd missed was the lack of break statements in the switch statement (I missed it, too).


The format they used for this was very successful, and I think it’s a nicer way to do this sort of thing than the approach I used at my TechEd talk.


Joshua Bloch is a very good presenter.

Expert Panel on Agile Java Techology-based Development

I didn't get a lot out of this. There was lots of good advice, but nothing terribly exciting.

I have a couple of BOFs that I'm attending later. I like the BOF concept, but having meetings at 10:30 when you've been up since 6AM isn't the easiest thing, especially when you're on your second night.



Comments (21)

  1. Chad Myers says:

    For us less-conference-savvy than you, what’s a "BOF"?

  2. Vaibhav Kamath says:

    Very nice, Thank you.

  3. Nicholas Allen says:

    Birds of a feather flock together. Or in other words, you get a bunch of people with interest in a particular topic together to talk.

    There’s a lot of interesting things you can do with class based enums, and they’re a lot more type safe than using integers, but I have no idea where that enum example is going.

  4. Nicholas Allen says:

    Ah, I think I get the enum example now. The foreach use is kind of bogus there.

    Imagine you were writing an interpreter and had a BinaryOp enum for all your binary operations. Someone gives you a BinaryOp op and two values left and right. You can say something like op.apply(left, right) instead of doing a switch. If you do it this way, you don’t have to worry about whether you’ve enumerated all the cases or someone has added new operations or anything.

  5. Pavel Lebedinsky says:

    I’m pretty sure some early versions (circa ’96) of Microsoft’s Java compiler allowed you to do something like

    import java.lang.Math;

    so you could write sin() instead of Math.sin(). I think this feature was removed later.

    I agree that this is the kind of syntactic sugar that should be kept out of a language (unlike, say, foreach(), which is also syntactic sugar, but an extremely useful one).

  6. John Rusk says:

    >Static import is a feature to allow you to write something like “Sin“ rather than “Math.Sin“. I don’t think this is good for a language to do.


    Could you elaborate on the reason why you think it’s not a good thing?


  7. Eric Newton says:

    I’ve always been somewhat disappointed by not being able to treat enums as "structs-as-ints" and be able to write a few methods for the enum.

    especially a static .Parse method, (knowing that System.Enum.Parse works but obviously is a lot more verbose than, say Integer.Parse

  8. A slightly more obvious example of the methods-on-enums benefit might be a toString() method, so that you could write:

    System.out.println("Your car is a " + Cars.ECONOMY.toString());

    and get "Your car is a Chevy Cavalier" as output.

  9. Jonathan Pryor says:

    I’m not aware of any *shipping* games that use C#, but there has been at least one mention on the Mono lists from a game developer asking for assistance and ideas:

  10. Joe White says:

    In one of our apps, we have several different UI states (read-only mode, edit mode, a few others). Each of these states drives multiple UI elements: header text, imagelist index, enabled state of several different menu items, etc. If enums had virtual methods, I would have used enums as an implementation, and given each enum value a HeaderText property, ImageIndex, etc. As it is, I have an abstract base class and several subclasses, which works — but logically, it *is* an enum. So their implementation of enums appeals to me.

    Actually, an enum with *non*-virtual methods would be useful in a lot of cases (especially for things like converting to and from display values, database representations, etc.), and that’s a feature I’d like to see. AFAIK, there’s no reason that an enum’s IL couldn’t contain methods.

  11. Miguel de Icaza says:

    I like the idea of the imports, or aliases or whaever other way to add this.

    Why should we use `Console.WriteLine’, when say, `print’ is probably a nice shortcut that should just be made available.

    It could be organized in nice namespaces with the application domain of your choice.


  12. Thong Nguyen says:

    Java enums *are weird*. Looks like they’re trying to solve a problem which would be cleaner with iterators.

    public delegate void Operator(double x, double y);

    public Operator Operators()


    // PLUS

    yield return delegate(double x, double y) {return x + y};

    // MINUS

    yield return delegate(double x, double y) {return x – y};

    // ETC


    foreach (Operator op in Operators())


    result = op(x, y);


    or even simpler (C# ever supports anonymous delegates)

    public delegate(double, double) Operators()


    // PLUS

    yield return delegate(double x, double y) {return x + y};

    // MINUS

    yield return delegate(double x, double y) {return x – y};

    // ETC


    foreach (delegate(double, double) op in Operators())


    result = op(x, y);


  13. Joe Cheng says:

    In .NET, I often find it very useful to use flag-style enums (so you can bitwise-OR together different enum members). Unless I’m missing something, you can’t do this with the Java-style enums.

  14. Stephen Leach says:

    The point of the methods on enums are [1] to reduce the need for explicit conditionals and [2] to avoid adding methods outside of class definitions. This second point arises because of the mess that the Java designers made when they conflated name spaces and classes.

  15. Stephen Leach says:

    I see no difficulties with static imports – quite the contrary. Their elimination was utterly misguided and it is good to see this mistake being redressed.

    The point of name space control is to properly balance the needs of managing the mapping from syntactic names to semantic values with conciseness and readability. Since writing Math.sin is not concise, not an improvement in readability and actually weakens the name space control, it is a straightforward mistake.

Skip to main content