Over the weekend I ran into an interesting design issue inside of ERRest. Java supports declaring generic methods that can perform a simple type inference:
public class NonGenericClass {
public T objectForKey(String key) { ... }
}
What this allows you to do is:
Person p = new NonGenericClass().objectForKey("person")
Notice that we don't have to cast to Person like you would if objectForKey returned Object. So ... is this bad form? The closest examples of Sun using type inference in the core libraries is Collections.emptyList(), which can give you a type-inferred List. The difference, though, is that this is an inherently safe operation. In the example above, that code is inherently unsafe. On the upside, your API becomes easier to use -- your users don't need to think about the cast. On the downside, you might say the API is misleading, implying that this operation is in some way typesafe when it clearly is not.
I came to a happy place with it. My decision was that if this API is impossible to make type-safe (think ResultSet.getObject(String)), and if that's fairly obvious to the user of the API, then taking advantage of type inference is OK and will just save your API users time.
One catch, by the way, is that javac appears to not like a double indirection of type inference:
public class ClassOne {
public T methodOne() {
return ...;
}
}
public class ClassTwo {
public T methodTwo() {
return new ClassOne().methodOne(); // this is a compile error in javac
}
}
For some reason, javac is not capable of returning an inferred type for a method call to a method that returns and inferred type. You have to cast to T:
public class ClassTwo {
public T methodTwo() {
return (T)new ClassOne().methodOne(); // this makes javac happy
}
}
Incidentally, the Eclipse compiler is fine with the first one and doesn't need the cast. I think this is a javac bug, personally.
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 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).