What this driver does:

Measurements

1. SQL exec performance (measured just before and immediatelly after execute... calls; also the number of total calls and completed calls of the SQL phrase, per connection).
2. FETCH performance (ResultSet) (the difference between times of the last next()/previous()... call and the first one).
3. TX performance (measured from the first update statement, number of statements executed whithin the transaction).
4. Connection performance, (measured both global and per connection - #statements, #exceptions, retention time per connection, max opened connections, etc). From this statistics you should be able to configure correctly the pools (if you use any).
5. Exception reports (the stack trace, how often they appeared).

Code problems

1. Deprecated methods usage.
2. Accessors - we named the accessor == the routine executing a certain SQL phrase. When we find the same SQL phrase in different routines, this means that there's a certain level of code duplication. This may be not so good ...
3. Use of not recommended syntax for the SQL phrases. For instance, instead of using SELECT * FROM mytable , you should use SELECT mycol1, mycol2, mycol3 FROM mytable. The reason is obvious.

Detected problems & tips

1. Resources are not closed (both resultsets and statements). It's maybe the most useful feature.
2. Connections are not closed.
3. Cache recommandations. In some applications, it may be a good ideea to cache some dictionary tables instead to get it each time you need it. If the same resultset is received for a certain period of time passing the same parameters, this SQL may be eligible for cache.
4. When you use pools, in certain configurations and for special kind of applications, and when connection warnings are never cleared, you may have the surprise to see the program consuming more and more memory. This is also analyzed by the driver.
5. Inconsistent use of AUTOCOMMIT. We cannot say what the developer wanted to do, but when the driver detects the same usage of some SQL phrase with a different AUTOCOMMIT setting, it will warn the user.
6. Inconsistent use of ISOLATION LEVEL. Same mechanism is in place here. If you reach the same point in your program but with another TX ISOLATION LEVEL set, it's almost for sure a mistake (somebody set it to some level and forgot it like that).
7. Monitors the usage of 'heavy' TX ISOLATION LEVEL (for SERIALIZABLE and REPEATABLE READ).
8. Monitors the usage of updatable result sets. This kind of resultset has the disadvantage that it places locks on the server side. If the update is driven by some interactive application, it may be a major bottleneck.
9. Unrecommended FETCH strategies. Warns if you use, for instance, reverse fetch instead of using a correct ORDER BY clause and a normal fetch.
10. ... and more ...

So what will be in the near future ?...

1. Hints for parallel execution
2. More log options (for now only plain files and stderr/stdout are supported - my plan is to support log4j and java.util.logging.* as well as a database)
3. More config options (xml, database)
4. A tool that will interpret the records gathered by this driver and will let you visualize the output.
5. More languages added. For now, only English is used (somebody should translate the resource files in German, French, Italian ...).