May 30, 2006
Trip report from Grand Cayman
I'm just back from a fantastic vacation in Grand Cayman and I wrote up a short trip report here...
May 25, 2006
Unfounded fears
I remember that when I discovered Java and realized that objects retrieved from collections needed to be downcast to the proper type, a painful decade of hard-learned C++ pitfalls immediately caused me to be worried about the potential unsafe aspect of this feature. I was pretty sure that I would soon be spending a lot of time debugging reams of ClassCastExceptions because of this "oversight". I wasn't alone.
But we were all wrong.
We know now that such errors are very rare and nobody would think of criticizing Java on this criterion any more.
A recent discussion about unboxing made me wonder if we were not making the same mistake again.
It started with this innocent-looking piece of code:
Map<String, Integer> lookupTable = new HashMap<String, Integer>();
int value = lookupTable.get("foo");
which, as of JDK 5, will throw a NullPointerException (a behavior which, in my opinion, is a Good Thing, and was almost unanimously passed by the JSR 201 Experts Group with a vote count of 19-1).
Do you remember the reaction of the community when the early proposals for boxing and unboxing were unveiled? If I recall correctly, everybody was afraid of one very simple thing: performance.
We all thought that all this hidden boxing/unboxing that silently translates simple pieces of code into expensive conversions would take a heavy toll on the performances of our applications, and so we all prudently stayed away from it "just in case". I'm still wary of boxing overall, but I have to say the performance concern has all but faded from my mind. However, I do occasionally find myself tripping on some unplanned side effect of the specification, such as the one mentioned above.
It's not very often, but once in a while, the crowd is not that wise.
May 16, 2006
Open sourcing Java: nobody cares
As JavaOne 2006 opens its doors today, the age-old question is bound to be asked again and again: will Sun open source Java?
I have a fairly straightforward answer: I don't care.
And I suppose that most of the Java developers out there don't care either.
What exactly is not open source in the Java we use today? I had to think hard to answer this question because, frankly, everything I need on a daily basis is already available in source form, with one exception: the Java Virtual Machine.
Sun's JVM (and others) is admittedly very good and I'm sure a lot of developers would be interested in knowing how it works, but let's face it: the inner workings of a Java Virtual Machine are completely irrelevant to most Java developers and not having access to this resource will probably never get in the way of writing Java code.
With that in mind, why is the question of open sourcing coming back so often?
One word: zealotry.
I find that most of the time, people asking this question are not so much Java developers than they are rabid open source fanatics who just want to make a point. In their eyes, not having access to the source of any software product is a personal insult that they want to see remedied regardless of the consequences or the price to pay. It's time to ignore these people and ask the people who really care: the Java developers. And I am pretty sure that if Sun asks them what they want, their answers will be much more along the lines of improving or fixing bugs in the existing platform than about open sourcing Java.
Having said that, there is one thing that Sun needs to fix about Java, and urgently: licensing.
For as long as I can remember (1996 I guess), distributing Java has been an incredible legal nightmare that has turned off a lot of companies and organizations that were extremely friendly to Java. I've worked at some of these companies and talked to many opeople working at these companies, and the message is uniformly the same: "We tried to work out a deal with Sun in order to include the JDK or the JRE, the talks took months, never went anywhere and we just gave up".
If Sun is lucky, these companies decided to ship their Java product anyway and recommended to download the JDK separately (clearly not a user-friendly way of proceeding), but in the worst cases, the companies simply decided to move away from Java and to turn to platforms that offer more friendly licenses such as... Windows.
Seriously.
Come on, Sun (and Jonathan): this is what we want to hear at the keynote, not some fluff, hardware sales numbers or how Java and XML go "glove in hand" (remember that one?).
Make it incredibly easy for individuals and companies to redistribute Java and you will see what "viral" really means.
As for myself, I'm too busy scuba diving in Grand Cayman to attend the keynote personally for the first time in ten years, but make no mistake: I'll be watching.
O
May 11, 2006
Statement modifiers in Ruby
Ruby supports a syntactic construct known as a "statement modifier". A statement modifier lets you move control structures at the end of an expression. For example, the following two examples are equivalent:
if c.empty?
return
end
return if c.empty?
I have always found this construct suspicious. After all, the saving is fairly limited (no need to close the block with end) and moving the logic at the end of the line is counter-intuitive for most imperative programming languages.
As I was re-reading some of the Ruby code I have written over these past months, I noticed a pattern on how and when I used statement modifiers, and it started making a little bit more sense. I say "a little" because I still think it's a feature that should be used sparingly.
I started realizing that statement modifiers shared a lot in common with exceptions. For me, they are a way to quickly handle error or trivial cases without impacting the readability of my code. In a way, it's an extension to the "early abort" approach, that I discussed in an earlier entry. If you're not using exceptions, early aborts or statement modifiers, you usually end up wrapping your logic in a big if and handling the other case in an else, which is not necessarily the most readable way to structure your code.
With statement modifiers -- and more generally, early aborts and exceptions --, the body of your methods remains focused on the business logic that is expected to happen "if all goes well", and other cases are moved out of the way.
Having said that, there are definitely a few usage patterns and conditions that must be met by the statement modifier if you want to keep your code clean. Your statement modifier should:
- Be simple. If it's going to span over several lines or
feature a complex boolean condition, you should be using a real block.
- Not perform any side effects. If it does, then you're doing business logic and not an early abort, and again, you should probably use a real block instead.
How do you use statement modifiers? Do you have examples of good ones? And, more interestingly, of very bad ones?
May 09, 2006
TestNG at JavaOne: guest speaker
As I mentioned in a previous entry, I will not be able to attend JavaOne this year, so I'm happy to announce that Hani has kindly accepted to give the TestNG talk on my behalf. Come meet the BileBoy in person and leave with a brand new outlook on Java testing!
See you all in a few weeks.