Beyond Java - Bruce Tate [49]
Code Blocks and Continuations
The Java open source community now uses anonymous inner classes with greater and greater regularity. When you need lightweight callback-style functionality, in Java the best way is the anonymous inner class. Here's an example of JDBC-style access in Spring, with the anonymous inner class:
JdbcTemplate template = new JdbcTemplate(dataSource);
final List names = new LinkedList();
template.query("SELECT USER.NAME FROM USER", new RowCallbackHandler() {
public void processRow(ResultSet rs) throws SQLException {
names.add(rs.getString(1));
}
}
);
Here's a code block in Ruby:
dbh.select_all("SELECT name, category FROM animal") do |row|
names << row[0]
end
This code example executes the code in bold for each row in the result set, which is passed into the code block's row variable.
For application programming, code blocks show up frequently. Any time you need to iterate through a collection, or a result set, or a file, code blocks come into play. Keeping them simple saves you a tremendous amount of work.
Continuations will also be important. In Chapter 8, you will see how continuations dramatically improve productivity in web-based programming.
Rapid Feedback Loop
Think of a feedback loop as the time between making a change and seeing the impact in running code. New application development principles, like test-first development, work best with a fast feedback loop. Small changes in the feedback loop can make huge differences in overall productivity, because you do it so many times every day. With Java, you need to deal with at least a compile step, and you often add steps for code generation (XDoclet), byte code enhancement (JDO), and deployment (servlets and EJB). For Java, that means you must wait to see a source code change realized in executed code. Developers tend to underestimate the benefits of a small feedback loop, unless they're regularly using a dynamic language and need to go back to a static language.
Smalltalk, Lisp, Perl, Ruby, and Basic all have rapid feedback loops, and they're also incredibly productive languages. C, C++, and Java don't. In fact, Java might not have succeeded if its users had come from a dynamic language supporting a rapid feedback loop.
User Interface Focus
More and more, I'm seeing experts that need to do significant user interface development move away from Java. Given the strong server-side focus of the past six years, that news should not shock any of us. Still, the number of Swing experts who vehemently defend it, without trying a meaningful alternative, confuses me, like two Titanic passengers arguing over which deck is prettier as the ship sinks around them. James Duncan Davidson said it best: "Friends don't let friends Swing." User interface development demands more than Java has to give. For most application developers, the framework should do much more for you.
Dynamic Class Model
The Java successor should be much more dynamic, and reflective. Java's reflection API is particularly hostile because it must deal with primitives , arrays, and classes. Let's look at a Java example of reflection. Here's a simple XML emitter provided by Stuart Dabbs Halloway, courtesy of DevelopMentor:
public static void doObject(Object obj) throws Exception {
Class cls = obj.getClass();
emitXMLHeader(cls);
Field[ ] fields = cls.getDeclaredFields();
for (int i=0; i < fields.length; i++) {
Field field = fields[i];
field.setAccessible(true);
Object subObj = field.get(obj);
if (!Modifier.isStatic(field.getModifiers())) {
if ((field.getType().isPrimitive()) ||
((field.getType().getNamxe() = = "java.lang.String"))) {
emitXML(field.getName(), subObj);
} else {
doObject(subObj);
}
}
}
emitXMLFooter(cls);
}
I've omitted the code to actually emit the XML, but you get the picture. Look carefully at the lines in bold. You had to deal with primitives a little differently, but I'm lucky, because for this particular problem, I can treat all primitives the same. That's usually not the case. I'm