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.