Skip to main content

Posts

Showing posts from March, 2007

Beware the hashcode!

(With thanks to my colleague Armand "jojo" Dijamco) What does this code print? Map map =  new  HashMap () ;      Collection things =  new  HashSet () ; things.add (  map  ) ; System.out.println (  things.contains (  map  ) ) ;      map.put (  "foo" ,  "bar"  ) ; System.out.println (  things.contains (  map  ) ) ; Be wary of storing mutable objects in a HashSet , or using them as keys in a HashMap . An implementation side effect of using a collection that relies on hash codes is that making changes to the object in a way that alters its hash code will cause it to no longer be considered the same object. There's no way (short of removing and re-adding the item from the collection) to inform a collection that a mutable object needs to be re-hashed. Item 13 in Josh Bloch's Effective Java tells us to "Favor Immutability". He also tells us in item 8 to "Always override hashCode when you override equals". A corollary

Unit testing Swing components - impossible?

Testing Swing components seems to fill many developers with fear. "How can I unit test this thing?" they often ask, "it's full of icky event handling code and troublesome painting...". Frameworks such as Abbot are often the solution developers find for this problem. Essentially, many developers abandon the idea of writing regular unit tests for Swing components, and resort to "click simulators" which are frequently functional tests rather than unit tests. There is a lot you can do just to test regular Swing components using bog-standard JUnit (or Test-NG) tests. Consider the following fairly basic Swing component. package  org.dubh.blog; import  java.awt.Graphics; import  java.awt.event.MouseAdapter; import  java.awt.event.MouseEvent; import  java.util.List; import  java.util.concurrent.CopyOnWriteArrayList; import  javax.swing.JComponent; /**   * A user interface widget.   */ public final class  Widget  extends  JComponen

What's up with the 2.0?

Well... If I was being more accurate, this would really be 4.0. In the beginning, there was Brian Duff's Weblog over on Radio Userland (good grief, that wasn't even Web 1.0. You had to install a thick client application just to post. Yowzers), then I set up Orablogs , and moved over to there. Until fairly recently, I blogged (or rather, mostly didn't out of laziness) at blogs.oracle.com . So why move now? Well. I got a wee bit frustrated with the blog management software I was using - it had a troublesome tendency to mangle Java code in particular, which is something of a pain when you're trying to write a Java coding related blog. So far, I'm pretty happy with blogger.com 's interface. Another reason for the move is that I want to blog about more random stuff outside the world of Oracle. For instance, if I decide to play with Eclipse or JBoss (perish the thought), blogs.oracle.com doesn't really feel like the appropriate place. Even though my blog

Check parameters for validity... good advice!

I recently ran into a weird NullPointerException in part of our code: Exception in thread "main" java.lang.NullPointerException at org.dubh.blog.Graph$Vertex.access$000(Graph.java:17) at org.dubh.blog.Graph.getVerticesConnectedTo(Graph.java:14) at org.dubh.blog.Graph.main(Graph.java:26) Hmm... access$000 ? That's odd. The code looked something like this: 01   package  org.dubh.blog; 02   03   import  java.util.ArrayList; 04   import  java.util.HashMap; 05   import  java.util.List; 06   07   final class  Graph 08   { 09      private  HashMap _vertices =  new  HashMap () ; 10   11      public  List getVerticesConnectedTo (  Object vertexKey  ) 12      { 13        Vertex vertex =  ( Vertex )  _vertices.get (  vertexKey  ) ; 14        return  vertex.fromEdges; 15      } 16   17      private final class  Vertex 18      { 19       private final  List fromEdges =  new  ArrayList () ; 20     } 21      22      public static  void  main (  String