Never hashCode on a mutable value Revisited

In the "Never hashCode on a mutable value" post, I talked about the pitfalls of using a mutable value in your hashCode/equals computation. Another subtle variant of this is using a Comparator for a mutable value in a TreeSet (or other similar data structures). Because the set is sorted internally, and optimized based on that sort information, if you change the sorted value of one of your objects in the set, it can "disappear" if you attempt to .contains(..) check it later. I wonder how many more of these stupid mistakes I'll find ...

Slow PS3 Wireless Connection

props to this guy ... if your PS3 wireless connection is ungodly slow, change your router from Mixed to G-Only. it's stupid, but it was about a 10x speed boost (... back to normal, basically).

Open Type can't find your class?

I ran into an annoying case when switching frequently between workspaces and doing some really mean things to a couple of them with swapping out external frameworks repeatedly. Somehow I managed to corrupt my type caches in Eclipse so that the Open Type dialog would just be missing some entries (which is REALLY annoying, I might add). This would also manifest as java type completion not working for the missing classes. Maybe there's a nice way in Eclipse to do this, but I couldn't find it, but you can toss your type caches. Quit Eclipse, go to workspace/.metadata/.plugins/org.eclipse.jdt.core and remove *.index and savedIndexNames.txt. When you restart Eclipse it will rebuild the entire type cache and life should be happy again.

JSEditor is gone, but not really

JSEditor disappeared from Adobe Labs and is not only available inside of Flex Builder, but it turns out that the install site is still there and is actually the same version included in Flex Builder. You can add the install site: http://download.macromedia.com/pub/labs/jseclipse/autoinstall/site.xml and it will install. You will probably need to set JSEditor to be your editor for *.js

Maclipse Eclipse 3.4.1 Updates

Maclipse has been updated with all the changes merged in from Eclipse 3.4.1 finally. Links on the right, same install process applies.

Never hashCode on a mutable value.

public class Terrible {
 public static void main(String[] args) {
  HashSet people = new HashSet();
  Person originallyMike = new Person("Mike");
  people.add(originallyMike);
  System.out.println("Terrible.main: Contains Mike? " + people.contains(new Person("Mike")));
  System.out.println("Terrible.main: Changing stored name from Mike to Adam.");
  originallyMike._name = "Adam";
  System.out.println("Terrible.main: Contains Mike? " + people.contains(new Person("Mike")));
  System.out.println("Terrible.main: Contains Adam? " + people.contains(new Person("Adam")));

 }

 public static class Person {
  public String _name;

  public Person(String name) {
   _name = name;
  }

  @Override
  public int hashCode() {
   return _name.hashCode();
  }

  @Override
  public boolean equals(Object obj) {
   return obj instanceof Person && ((Person) obj)._name.equals(_name);
  }
 }
}

prints:

Terrible.main: Contains Mike? true
Terrible.main: Changing stored name from Mike to Adam.
Terrible.main: Contains Mike? false
Terrible.main: Contains Adam? false

HashSet uses the hashcode of your object to select the bucket for your object. If your hashCode changes, the object effectively disappears from the collection for the purposes of API calls like .contains(..). So do yourself a favor and never use a mutable value in your .hashCode (which also, incidentally, means that you can't use a mutable value in your .equals(..) since those two methods are required to be mutually consistent).

Color is on the app store!

Enjoy! Color