Some of his observations are correct, but the conclusions he draws are iffy. Notice that after he slags Spring, he uses straight JDBC in his comparison examples.

but it required creating a subclass for each query

Incorrect:

counter = new SqlFunction(ds, "select count(quote) as lrpdcount from quote where board_id = ?");\ncounter.declareParameter(new SqlParameter(java.sql.Types.INTEGER));\ncounter.compile();\nSystem.out.println(counter.run(boardId));

where ds is a bog standard JDBC datasource instead of his own pooling object (who writes their own pooling objects these days? Wait, don't answer that...). See the user queries below as well.

His example with the recordset is a bit disingenuous, since very rarely do you just want to print out a tabular query result. See the last example below.

learning a somewhat complicated exception hierarchy

As Chris pointed out, the exceptions are unchecked. If your exceptions signify a fatal condition (which is most of the time), then you want them handled by a central handler, and you don't have to know jack about the exception hierarchy.

Here's the equivalent code to his error checking example (except that I actually used braces like you should, instead of trying to make the code look tiny by omitting them...):

try { some data access code here }\ncatch (DataIntegrityViolationException v)\n{\n    applyDataIntegrityViolationRecovery();\n}\ncatch (DeadlockLoserDataAccessException d)\n{\n    applyDeadlockRecovery();\n}

So, learn a slightly complicated exception hierarchy, or learn a slightly complicated method call API. Note that an exception hierarchy allows you to stack your error handling more easily without if/then tests in each stack.

Looks to me like he copied Spring with a slightly different API (and probably a lot less functionality). Some of what Spring does allows you to manage your transactions outside of the data access code itself, for example. Spring also allows you to use things like Toplink or Hibernate with the same exception handling.

requiring framework users to implement anonymous inner classes.

this.allUsersQuery = new MappingSqlQuery(ds, "SELECT * FROM users")\n{\n    protected Object mapRow(ResultSet rs, int count) throws SQLException\n    {\n        return new User(rs);\n    }\n};\nthis.allUsersQuery.compile();\nList users = this.allUsersQuery.execute();

<dry>Oh, that was difficult.</dry> Notice the convenient lack of loop processing to run through the result set, such as SQLExecutor requires.

Or if you want to parameterize it:

this.userQuery = new MappingSqlQuery(ds, "SELECT * FROM users where user_id = ?")\n{\n    protected Object mapRow(ResultSet rs, int count) throws SQLException\n    {\n        return new User(rs);\n    }\n};\nthis.userQuery.declareParameter(new SqlParameter("user_id", Types.VARCHAR));\nthis.userQuery.compile();\nUser u = (User) this.userQuery.findObject("spork");

Owing to Spring's callback nature, you can do a lot fancier things as well, such as processing a stored procedure's returned cursor transparently.

Now, you're not strictly required to subclass things to do your queries, but if you do, you can create a more object-oriented approach to data access. I'm not sure why he thinks this is a bad thing.

Example combining the above:

private class UserQuery extends MappingSqlQuery\n{\n    public UserQuery(DataSource ds)\n    {\n        super(ds, "SELECT * FROM users");\n        compile();\n    }\n\n    public ViewRegMappingSqlQuery(DataSource ds, String where)\n    {\n        super(ds, "SELECT * FROM users WHERE " + where);\n    }\n\n    protected Object mapRow(ResultSet rs, int count) throws SQLException\n    {\n        return new User(rs);\n    }\n}\n\nthis.allUsersQuery = new UserQuery(ds);\n\nthis.userQuery = new UserQuery(ds, "user_id = ?");\nthis.userQuery.declareParameter(new SqlParameter("user_id", Types.VARCHAR));\nthis.userQuery.compile();\n\nthis.loginQuery = new UserQuery(ds, "user_id = ? AND password = ?");\nthis.loginQuery.declareParameter(new SqlParameter("user_id", Types.VARCHAR));\nthis.loginQuery.declareParameter(new SqlParameter("password", Types.VARCHAR));\nthis.loginQuery.compile();\n\nthis.lemurQuery = new UserQuery(ds, "country = 'Madagascar'");\nthis.lemurQuery.compile();

Now, granted he does say that he's just trying to make a very simple SQL framework, but I really don't see the added benefits. And as soon as you do something that he didn't allow for in his framework, you're reduced to either using straight JDBC, mixing frameworks, or rewriting the entire thing. I'll go with the tool that I know can handle anything to start with.

[Edit: slight formatting changes, fixed bug with WHERE clauses in last example]

Error in transcription, sorry.