I’m just back from a fantastic vacation in Grand Cayman and I wrote up a short trip report
here…
Archive for May, 2006
Unfounded fears
May 25
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.
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
Statement modifiers in Ruby
May 11
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?
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.