Built my first PreparedStatement with parameters yesterday. I was delighted to see that I just use question marks in the SQL to indicate parameters, as I'm used to from DBI. And then I was startled when execute() didn't seem to work when called with those parameters.
Poor, poor JDBC. Being hosted in a language such as Java, execute can't seem to handle a varying parameter list. There's a Java provision for variable-length parameter lists, but not really a decent way to handle parameters that might vary in type as well. Everything could be wrapped up in an object, but that would just be messy.
So I have to bind the variables to the statement before I execute it. And then came the part that really made me laugh mockingly: you don't just say set(pos, variable). You have to say setType(pos, variable): there's setInt(), setLong(), setString(), etc. Even setBlob(), setNull(), and setBigDecimal(). How sad.
However, I must say that I am impressed by setDate(). I always wanted to do that in DBI. Of course, I didn't want to have to bind each parameter independently or worse, use a different method for each type of variable, to do it. I wanted DBI to give me Time::Piece objects, or DateTime objects, or whatever I preferred at the moment. (I probably would've been happy even if it had given me a date object of a type I didn't prefer.)
On another JDBC note, the Statement class makes no sense to me. Statement objects do not seem to actually represent SQL statements unless they are one of its subclasses, yet Statement is not an abstract class. The documentation for Connection.createStatement() even refers to them as "a Statement object for sending SQL statements to the database." Statement has a method to call SQL statements, which is strange.