Code By Number | codebynumber.com

Alex Miller writes about code spelunking techniques for when you’re digesting someone else’s code. He offers some good advice, particularly for tracking down call hierarchies and implementors (and some useful Eclipse shortcuts). What was missing, I thought, was the easiest one of all:

Draw a picture.

He did show a project dependency graph, but I find it’s really best to draw a simple picture, not even in UML, just in whatever comes naturally to you. On this picture, keep the real names of the classes, but then give them useful names, or small summaries, and describe their general responsibilities.

Use this diagram as your map, and don’t complete it for perfectionism, but only follow interesting paths. Invariably you’ll end up pruning paths as it’s clear that it leads to property holders, or utility functions (which is part of classifying the objects, as Alex writes) in which you’re not interested. But in particular, when you draw your own diagram, you have a bread crumb trail to look back on, so when the names don’t make sense, or you can’t remember the big picture, you’ve got your notes of what you’ve already seen.

Besides, if you’re drawing a picture, then the next developer who comes along will need to draw a picture too. So you might be able to do a formal diagram and put it into the project, helping others pick up on the architecture that much faster.

I have been experimenting with Java3D and JOGL as 3D libraries. Both are mature, and perfectly acceptable for anything I would be doing with them.

Java OpenGL uses JNI (meaning the underlying system must support OpenGL), and it doesn’t use Java3D’s scene graph approach. With Java 6, Java2D and JOGL can work closer, resulting in swoopy features like a Swing button with a 3D icon image.

Java3D was meant to be a Java wrapper for DirectX and OpenGL. It, too, uses JNI, and it seems there is no sophisticated 3D graphics library that doesn’t. But, as Alexander Schunk writes, JOGL makes Java3D somewhat ineffective as a unifying library among the 3D graphics technologies.

So, I don’t know which I will go with. There are some fantastic books on OpenGL, and it’s certainly a useful skill set. It’s too bad you can’t easily port things over from OpenGL to the scene graph API of Java3D. They’re such different approaches, but that’s why they’re two distinct projects.

Ah hah! The solution to my database woes was the PreparedStatement.

The only serious database-intensive application I’ve written used PHP’s Pear DB package. And PHP was just a lot nicer about typing and variable substitution, so I found myself doing less of the quote-escaping and type checking necessary in Java. So it is with great relief that I discovered prepared statements.

It works just like a regular statement, in that you create it off the connection:
PreparedStatement prepstmt = conn.prepareStatement("SELECT * FROM ITEMS WHERE NAME=?");
But, as you can see, the SQL string substitutes values with question marks. The fantastic thing about it is that this statement is not typed. By this I mean that you can put an integer or a string into the statement without changing the SQL. This cleans up a lot of the messiness of the SQL requirement of having single quotes surround strings. And because Java String concatenation is ugliest for short strings, it cleans up your SQL statements several fold, in my opinion.

To set it, all you have to do it:

prepstmt.setString(1, "myname");
ResultSet rs = prepstmt.executeQuery();



So here’s a before:

int rows = stmt.executeUpdate(”INSERT INTO “+
“ConfigData (configkey, configname, “+
“configdate) VALUES (”+configKey+
“, ‘”+configname+”‘, “+configdate+”)”);



And the after:

String sql = "INSERT INTO ConfigData(configkey, configname, configdate) VALUES(?, ?, ?)";
... //Create the prepared statement object
prepStmt.setInt(1, configkey);
prepStmt.setName(2, configname);
prepStmt.setDate(3, configdate);



Even without the performance gains of re-using these PreparedStatements, the cleaner String notation is a great solution for queries with several variables.