java

Java 5 pitfall

Java 5 has some nice improvements over Java 1.4 that really make writing code simpler… Then again sometimes simpler also means dangerous. Case in point, Java 5 auto-boxing. Consider the following method:

public Boolean isValid()
{
  // if we don't have any data, we cannot decide so we return null,
  // which is why we're using Boolean instead of boolean
  if(data == null)
  {
    return null;
  }
  else
  {
    // data.isValid() returns a Boolean
    return data.isValid();
  }
}

As you can see, we are using Boolean as a return type to provide a ternary result instead of a simple true/false decision: sometimes, we just don’t have enough information to decide and we want to know that. So far so good!

Now, we’d like to use this method within a test:

...
if(isValid())
{
	//do something...
}

This code compiles with Java 5 thanks to the auto-boxing mechanism. It would be an error with Java 1.4, however, the compiler in Java 5 transparently converts the Boolean return value to a boolean. Everything seems great: we have a method that provides more information and the code is as easy to read as it was with a method that simply returned a binary result. Except that now, this last piece of code can actually fail and cause a NullPointerException because the compiler converts the code to something similar to:

Boolean tmp = isValid();
if(tmp.booleanValue())
{
	// do something...
}

thus causing the NullPointerException if tmp is null… Tricky!

Now, this is nothing new (though I only realized it when I was about done with this post), it’s been pointed out several times already… However, I stumbled on it just now and though I figured out pretty quickly, it was still somewhat surprising. On the other hand, the advantage of only starting to use a Java version so late after it’s been released is that all the potential pitfalls are fairly well documented by now! :)

State of Java on OS X

It’s fairly common these days to hear about how Java on the Mac is doomed. Sure, I’d like Apple to put more emphasis on Java on OS X but I also know that Apple runs a very tight ship and resources are constrained (see how Leopard was delayed to work being done on the iPhone). Despite all this, the Java team at Apple has managed to provide reasonably good release of Java for OS X. Considering how small the team is, it’s quite an achievement. Charles Miller has summed up the situation quite well so next time someone’s hair catches on fire because supposedly Java is doomed on OS X, just point them to his very well written post.

Activating dev mode in JBoss Portal

By default, portlet errors are swallowed up by JBoss Portal but you can change that so that errors such as portlet unavailability, etc… are displayed. To achieve such result, you should modify the config.xml file in portal-core.sar/conf so that the properties to show/hide the appropriate errors are to your liking:

<properties>
    <!-- When a window has restrictedaccess : show or hide values are permitted -->
    <entry key="core.render.window_access_denied">show</entry>
    <!-- When a window is unavailable : show or hide values are permitted -->
    <entry key="core.render.window_unavailable">show</entry>
    <!-- When a window produces an error : show or hide values are permitted -->
    <entry key="core.render.window_error">show</entry>
    <!-- When a window is not found : show or hide values are permitted -->
    <entry key="core.render.window_not_found">show</entry>
</properties>

Getting unexpected results with String.split?

I have been wondering for the last 40 minutes why the hell my String wouldn’t split the right way. Turns out the separator I’m using is a reserved character in the regex syntax (‘|’ to be precise) and I forgot to escape it. Not obvious when you’re used to passing just Strings as the regex… So if

String.split

is giving you a hard time with a seemingly simple String, check that you’re not using a reserved character… and if you do, escape it:

someString.split("\\|");

:)