Maclipse 3.4.2 Fixed ... More

You may have noticed that Java=>Editor=>Templates throws an exception with Maclipse ... That's because there is some code that presumes there is a non-null vertical scrollbar. With Maclipse, we autohide scrollbars on Leopard, which causes an NPE in that code. I avoided fixing this because it brought in an entirely new plugin that we had to hack, but it's just one line, so .. meh.. at this point, why stop now.

So to prevent that exception, you will want to grab the Workbench Texteditor UI plugin provided in the links area.

cd /Developer/Applications/eclipse/plugins && curl -O http://webobjects.mdimension.com/wolips/preview/org.eclipse.swt.carbon.macosx_3.4.1.v3452b.jar && curl -O http://webobjects.mdimension.com/wolips/preview/org.eclipse.ui.workbench_3.4.2.M20090127-1700.jar && curl -O http://webobjects.mdimension.com/wolips/preview/org.eclipse.ui.workbench.texteditor_3.4.1.r341_v20080827-1100.jar

Maclipse 3.4.2 Fixed

The build from last night was missing a MANIFEST.MF, so it wasn't exporting the plugin info properly. I think this would only be a problem if you do plugin development, but regardless, you should grab the new build.

Maclipse Eclipse 3.4.2 Updates

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

cd /Developer/Applications/eclipse/plugins && curl -O http://webobjects.mdimension.com/wolips/preview/org.eclipse.swt.carbon.macosx_3.4.1.v3452b.jar && curl -O http://webobjects.mdimension.com/wolips/preview/org.eclipse.ui.workbench_3.4.2.M20090127-1700.jar

You may also need to remove your eclipse configuration/org.eclipse.osgi/bundles folder (which contains the unjar'd SWT jnilibs).

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.