In the Java platform we have tended to focus on adding lots of
power and flexibility. That's great, but sometimes that power
and flexibility can get in the way of doing common tasks. As
part of the Ease-of-Development initiative we have been focusing
on simplifying common tasks and getting rid of unnecessary
boilerplate code.
Here are my five of my favorite cleanups so far:
#1: Opening a Text File
In JDK 1.1 to 1.4, in order to open a simple text output file
you needed to do:
FileWriter fout = new FileWriter("fred.txt");
BufferedWriter bout = new BufferedWriter(fout);
PrintWriter pout = new PrintWriter(bout);
Say what? Why are we having to type three "new"s in order
to do what should be a simple operation?
In Tiger we have finally added direct support for the common case
and now you can do:
PrintWriter pout = new PrintWriter("fred.txt");
This is an interesting example of a common glitch in our thinking.
In the Java platform we often like to provide lots of well designed,
well separated components that can be plugged together in interesting
ways. In fact some people might argue be that the design is cleaner
if the PrintWriter class doesn't know anything about files. Well,
personally, I don't think so. I think it is good to provide clean,
well separated components, but we also need to provide simple
shortcuts to support the most common use cases.
#2: Avoiding the Content Pane Pain
In JDK 1.1 to 1.4, if you wanted to add a Swing GUI component to
a container you simply said container.add(component).
Well, yes, except that if the container happened to be a JFrame
you would get a helpful runtime exception saying that you ought
to be saying
frame.getContentPane().add(component);
Umm, say what? Rather than raising the exception, couldn't the
JFrame.add method itself call JFrame.getContentPane().add()?
Yes it could. And in Tiger it does. Now you can just call add,
as you would with any other container object.
frame.add(component);
This only saves a few keystrokes, so is this really a big deal?
Yes. The real saving is that you can avoid having to learn
a whole new unnecessary concept. The reason that the
JFrame.add method originally threw an exception was because
JFrames actually support three different panes (content,
glass and root),
and it was
considered important to educate developers about those choices.
Well, I've written various Swing applications over the
years and I've never actually found the need to exploit the various
different panes. The old behavior of JFrame.add
forced me to go away and learn about panes. And that was
distracting and unhelpful. The lesson here is that (once again)
it is normally better to provide simple sensible defaults and to
avoid forcing people to learn about complex options.
#3: Self Registering JDBC Drivers
Since JDK 1.1, in order to load a JDBC driver, you needed to do:
Class.forName("com.fred.FredDriver");
Connection con = DriverManager.getConnection("jdbc:fred:fredsite.com");
Umm, what exactly is that Class.forName doing there?
This one is my fault. Back in the early days of JDBC, we needed a way
for the JDBC DriverManager to locate drivers. We arranged that newly
loaded driver classes would register with the
DriverManager. And then we asked that developers call
"Class.forName" to force the driver class to be loaded.
Sigh. This is an ugly wart. I'm happy to report that this one is
going away as part of JDBC 4.0 in
Mustang. The JSR-221 Expert Group
is adding a new mechanism so that the JDBC DriverManager can locate
and load driver classes without the need for developers to explicitly
type Class.forName. So you will be able to just do the obvious:
Connection con = DriverManager.getConnection("jdbc:fred:fredsite.com");
#4: Locating Resources in J2EE
In J2EE 1.4, if you wanted to locate a reference to a remote EJB you needed to type:
Context context = new InitialContext();
Object obj = context.lookup("fred");
FredHome fred = (FredHome) PortableRemoteObject.narrow(obj, FredHome.class);
Yikes. What on earth is going on with that PortableRemoteObject.narrow?
I have to confess that I'm one of the prime culprits here and, given some of
the constraints, it may have been unavoidable. But I think this one definitely does
win "Ugly Boilerplate of the Year".
As part of Java EE 5,
there are now specific mechanisms for dependency
injection, so you can now replace that code with a simple annotated
field definition:
@Resource FredHome fred;
And then the Java EE runtimes will take care of locating the resource,
doing the "narrow" for you and injecting the resource object into your field.
By default the resource name is inferred from the field name and the
type is inferred from the field type.
This is an example of using JSR-175 annotations to restructure how we
handle a common task so that it can become much simpler. I'm very
excited with what is happening with annotations as part of Java EE 5
- I think it is allowing us to greatly simplify Java EE programming.
And I'd like to find more ways to use annotations in Java SE, too.
#5: Iterating over Collections
My last example is from Tiger. We've all been used
to typing some standard boilerplate for iterating over collections, such as:
Vector<Wombat> v = getWombats();
Enumeration<Wombat> e = v.elements();
while (e.hasMoreElements()) {
Wombat w = e.nextElement();
...
}
Josh Bloch successfully argued for a language change to make it easier
to iterate over both collections and arrays, so now in Tiger we can do:
Vector<Wombat> v = getWombats();
for (Wombat w : v) {
...
}
We all knew this would be useful, but I have been really surprised by how
much I have enjoyed using it, for both arrays and collections. This
has turned into one of my favorite Tiger features. The resulting code
is distinctly easier to read, partly because we have managed to eliminate
an unnecessary local variable.
This is an example of fixing a boilerplate problem we barely realized
we had. I'd like to find a few more things like this!
To be continued...
I'll continue this topic in my next blog.
]]>