Am 23.10.2013 um 02:12 schrieb Tom Dunstan:
> and create subclasses of the various concrete statement classes which
> could be used when a debug flag is switched on. e.g.
> DebugJdbc3Statement, DebugJdbc3PreparedStatement,
While this could be beneficial from the "one jar to rule them all"
standpoint, I think this is too much hassle.
> IMO tracing non-closed statement leaks is probably better done in a
> connection pool or jdbc debugging library anyway, so maybe we
> shouldn't bother and just remove it.
Yep.
I think we could just have two jars
psql-debug.jar -- provide very loud logging if Statements and Connections
are not explicitly closed, which can be used for development and debugging.
psql-prod.jar -- without finalize() calls for integration, performance testing and
production
> One question is this, though: how many users out there aren't closing
> their statements currently and are relying, accidentally or
> deliberately, on the current behaviour?
Deliberately relying on the current behavior is just bogus and I guess
no one will know if they accidentally rely on it :-)
Besides that: tools like Findbugs or IntelliJ IDEA warn you when Statements
are not closed as they consider that a leak.
--
Heiko Rupp hwr@pilhuhn.de
Blog: http://pilhuhn.blogspot.com @pilhuhn