Mike Bowler

I just got back from the Toronto Rails Pub Night. Although this is the first one of these I've been to, I believe they've been meeting monthly for a while now. As you might suspect from the name, the conversation centered mostly around Ruby and Rails and was quite enjoyable.

Back in 2000 I started hearing buzz about an interesting language called Ruby. Every couple of weeks, I'd see some reference to it would wonder what it was all about. Finally, I took the time to learn how to program in it and I haven't looked back.

We all know how popular Ruby has become today. In 2000, however, Ruby was an unknown language that was just starting to generate a bit of interest.

Today, I'm seeing the same kind of buzz about a different language. Every couple of weeks, I see a reference to this language and I'm wondering if it's going to become popular in the same way that Ruby has. This new language is called OCaml and is the Object Oriented variation of Caml which is a functional programming language.

It will be interesting to watch this one to see what happens with it.

There is a lot of talk about dynamic languages (specifically ruby) these days and as a result, one question that keeps coming up is "does this mean that Java™ is dead?".

To my mind, the answer to that is an emphatic "no". Java™ is not dead and will in fact be around for a long time to come.

What I do believe to be true is that the Java™ language is past its peak. I believe that the market for the Java™ language is now starting to decline and will continue to do so as we go forward. This does not mean that Java™ is about to disappear or that it is any less relevant than it has been. What it means is that the market for the Java™ language is going to be slowing shrinking over time.

The Java™ Virtual Machine (JVM) on the other hand, does not appear to have reached its peak yet. I fully expect that other languages running on the JVM will become more of the norm going forward. JRuby in particular is getting a lot of attention these days although it is by no means the only alternative language running on the JVM.

The key that seems to be triggering the "is it dead" question seems to be a confusion between usefulness and excitement. Java™ is no longer exciting although it is certainly still useful. People are seeing huge productivity improvements with dynamic languages like ruby and this is very exciting. The buzz obviously goes with the excitement and so its easy to see why there isn't a lot of talk about Java™ these days.

It's worth noting that the dynamic languages aren't just "buzz". There are very real benefits to using a dynamic language and I think this trend towards more dynamic is a very positive one for the industry. Having said that, there are still times when Java™ is the more appropriate language choice.

Charles Nutter has an interesting demo on his blog. He's running an IRB session inside a Java™ applet embedded in his blog post. Given that JRuby runs inside the JVM, we can now run ruby any place that we can run Java™. It hadn't occurred to me that we could use this to run ruby code inside the browser although Charles shows that it's quite possible.

I see that Colorado Software Summit has already announced the dates for next year... October 21-26, 2007.

I'll be there. Will you?

Mark Reinhold (chief architect for Java™ SE) has announced on his blog that Sun's implementation of Java™ will be released under the GPLv2 license. Tim Bray, also from Sun, follows up on his blog.

Apparently official announcements will be made later today.

For a very long time in Java™, when you got a NullPointerException, it was fairly easy to identify those places on a line that could have thrown the exception. If you got a NullPointerException on the following line, for example, there is only one possible place where a null could have occurred - the variable 'map' must be null.

String value = (String)map.get(myKey);

Starting with Java™ 5, there are now some functions that can throw a NullPointerException without being obvious about it. Take this snippet for example. Can you see where a NullPointerException could be thrown on the first line?

boolean allowed = isAllowed();

System.out.println("allowed="+allowed);

It can if the method isAllowed() is declared to return a type of Boolean (not boolean). In this case, the return value will be autoboxed into the primitive form and if the returned value was null, a NullPointerException will be thrown during the autoboxing. I've been tricked by this one.

How about this next one. Can you see where the NullPointerException would be thrown from the first line?

for( String value : get(key) ) {

    doSomething();

}

I spent some time looking at something similar this afternoon. Under the covers, the result of get(key) will have its iterator() method called so if the method returns null, the code will blow up with a NullPointerException.

I really wish that Sun had provided more information with the NullPointerException. It's always been a guessing game to see where the exception came from and the guessing has become more challenging with the addition of autoboxing and the enhanced for loop.

In ruby, when you try to call a method on nil, it gives you an exception that tells you exactly what method was being called when the nil was detected. If Java™ did something similar then it would go a long way to helping debug these kinds of exceptions.

I just stumbled across this article that claims to defend the complexity of J2EE.


The interesting part to me is the assumption that these technologies are part of J2EE. In fact, none of them are. Not one.

ANT solves a problem not addressed at all by the J2EE spec. Struts and Tiles were built to sit on top of servlets (which are part of J2EE) and to provide a framework that was missing from J2EE. Hibernate is an alternative for the flawed¹ persistence model in J2EE. Spring was designed to counter the complexity that was overtaking J2EE. Same for XDoclet. AOP is an attempt to make Java itself more powerful and is not used at all by J2EE.

J2EE is getting bashed for good reason. The core spec doesn't do what most people need and consequently a large number of frameworks, like the ones above, have been created to build upon, and sometimes work around, the platform. Many of these frameworks are quite good, however, none of them are actually part of the J2EE specification.

¹ EJB3 fixes the main issues with J2EE persistence, however, adoption of EJB3 is slow and I expect the majority of the market to be stuck on EJB2.x for quite some time.

Over the last couple of months, I've been listening to an awful lot of podcasts. Now that we've moved out to the country, my commute is longer and podcasts make the drive to work pass very quickly.

I've found that podcast quality really varies significantly. Some are absolutely fabulous while others are a waste of time.

My absolute favorite at the moment are the TED Talks. These are recorded sessions from the TED Conference and features some of the most interesting speakers from around the world. Each speaker is given eighteen minutes to tell their story and the stories are amazing. All the speakers are passionate about their topic and most of them have a fabulous presentation style.

This morning, for example, I listened to Ben Saunders recounting his solo trip to the north pole. An amazing story of endurance and determination.