Other articles

1. More Thoughts on Apple and Java

   A few more points that occurred to me, following up on my last post.

   Whither the Mouse?

   Since its inception in 1984, the Mac user interface has obviously been designed for desktop computers with a mouse and a keyboard. When notebook computers came along and we wanted to be able to use them without carrying a mouse everywhere, or without even a flat, stable surface to put the mouse on, they had to emulate the mouse as best they could. This may now be reversing.

   In the announcement of Mac OS X Lion, there was great emphasis placed on the ...

   read more

   There are comments.

2. Java and the Mac

   So Apple has quietly announced that it is deprecating its support for Java on the Mac. The wording was (not uncharacteristically for situations like this) a bit vague on the details of what this means. I think two things are definite: 1) Apple will continue to support Java 6 on Snow Leopard until it reaches end of life; which I think happens when the OS after Lion is publicly released. 2) Apple will not port Java 7+ to the Mac. The main unresolved question is whether Java 6 will be supported on Lion. My guess is that it will be ...

   read more

   There are comments.

3. Logging vs String Construction

   A classic logging problem in Java is this:

   logger.finest(expensiveStringConstruction());
   

   The problem with this is that even when the logger’s level is above FINEST and the message is not logged, the message string must still be constructed. In cases where constructing the string involves a lot of work, your code can be slowed down significantly even when logging is off. The standard solution is like so:

   if (logger.isLoggable(Level.FINEST)) {
     logger.finest(expensiveStringConstruction());
   }
   

   By adding the if statement around the logging, the expensive string construction is only done if the message is actually going to be used ...

   read more

   There are comments.

4. XML vs Streams

   Ever get the feeling that XML sometimes makes things harder than they need to be? One of the problems that I and others have run into is that when parsing XML using SAX (or, in my case, using JAXB to unmarshall XML, which uses SAX under the hood) from an InputStream, the stream is always closed after the parsing is complete. This is surprising behaviour in Java, because you’re not supposed to close streams you don’t own. This can be a problem when using network sockets or when you want to write two or more unrelated XML documents ...

   read more

   There are comments.

5. Java’s clone mechanism is teh suq

   Doing cloning properly in Java is way harder than it should be. I thought I knew all the traps, but recently found yet another. In a nutshell, making inner classes cloneable is almost always a bad idea. The reason is that inner classes have an internal reference to an instance of their enclosing class, which is implicitly final and can’t be changed as part of a clone. For example:

   class Outer implements Cloneable {
       int i = 0;
       Inner inner = new Inner();
   
       public Object clone() {
           try {
               final Outer clone = (Outer)super.clone();
               clone.inner = (Inner)inner.clone(); // A.
               // Cloned inner still ...

   read more

   There are comments.

6. Handling InvocationTargetException

   A quick hint on handling java.lang.reflect.InvocationTargetException.

   This sucker is thrown whenever you invoke a method via reflection (typically via Method.invoke), and that method throws any sort of exception. So it doesn’t indicate a problem with the reflection mechanism, it is simply how the reflection mechanism notifies you of exceptions thrown by the method you called.

   Whenever you catch this exception (and you will have to catch it at some level), the first thing you should do is call getCause(). This returns the exception thrown from the method that was invoked via reflection, and that’s ...

   read more

   There are comments.

7. How Not to Catch Exceptions

   When it comes to bad Java practices, top of my list would have to be catching exceptions like this:

   try {
      // stuff - anything really
   }
   catch (Exception e) {
      // maybe log it if you're lucky
   }
   

   This is usually done because the “stuff” throws more than one kind of checked exception, and the code to handle each case is the same. So what’s wrong with it? The biggest problem is that this not only catches the checked exceptions you’re interested in, but also all RuntimeExceptions. The vast majority of RuntimeExceptions are only thrown from buggy code, and catching them ...

   read more

   There are comments.