This is not a tag line!
java
Beware of File.createTempFile
Sep 4th
By default, File.createTempFile (in Java, of course) creates a temporary file in the directory identified by the system property java.io.tmpdir. The problem is that on OS X, that directory can be quite weird. For example, on my system, it currently is:
scala> System.getProperties().getProperty("java.io.tmpdir")
res0: java.lang.String = /var/folders/ya/yaNATrKPGFu2HuSOWxSIu++++TI/-Tmp-/
Notice the ++++ in one of the directory names? Well, these little characters can later cause headaches! The reason, you ask? Simple, if that temporary file name is ever used in a URL, then those plus signs will be interpreted as spaces and whatever code is using a URL to find your temporary file will not find it! So beware!
Possible solutions include passing -Djava.io.tmpdir="whatever" when you launch your Java process, or use the createTempFile(String prefix, String suffix, File directory) version of File.createTempFile and pass it a directory that doesn’t contain an + sign in its name!
Java 5 pitfall
Nov 14th
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
Jun 29th
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
May 16th
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?
Apr 20th
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("\\|");
