I actually like SQL. So, things like Hibernate with it's own query language don't quite fit my style. But, I don't want to code the same catch SQLException conn.close over and over either. So, I came up with this.

The idea is you extend SQLCommand (usually anonymously) override getSql(), and call execute() to get a list of whatever objects you are selecting - all the cleanup stuff is taken care of. It also handles nullable attributes more intuitively using ResultSetWrapper and PreparedStatementWrapper so that in your overridden getRow(ResultSetWrapper rs) method, you can call getInt on a nullable column and have it return null - what a concept! Also I like java.util.Date for my dates, so the wrappers convert to/from java.sql.Timestamp.

Right now I've only bothered with some basic types - it should be pretty clear how to add more if you need em.

See what ya'll think.

Oh, it uses JDK 1.5 Generics, but stripping that away would be pretty easy if you wanted 1.2 compliance.

A handy class I use all the time to encapsulate the idea of whether two events coincide. For example, given a time period representing a shift, and a list of time periods representing transactions or sessions or whatever, find which ones are either totally or partially within the time period. This class make it a bit easier.

Do you find yourself implementing toString on your objects all the time, and wondering why (the debugger seems to do a pretty good job of it all by itself)...well, here's a bit of introspection applied to the problem. This is for all those quick debug sessions where you just want to do System.out.println(myComplexObject).

Instead, just do System.out.println(DebugPrint.toString(myComplexObject));

Here's a nifty trick I often use for testing.

Lets say you have a c:\foo\lib directory full of jarfiles for log4j, javamail...whatever.

Modern J2EE containers do a nice job of letting you deploy a jarfile with your code and have a lib directory full of jarfiles like this, but what if you just want to run a quick client from the command line?

Here's what you do:

Another solution recommends using a text match pattern.
This works, but as long as you've got mail.jar in your classpath anyway, you might as well use this technique instead. (Plus, I think it works with older JDK 1.2+, whereas pattern.compile is 1.4+)

Note that it also accepts a comma-separated list of emails, just like a To: or CC: address line would.

Implementation of file_put_contents for PHP4

Get File Extensio

Get File Size

Find File

Set's a filter for what files to accept when using JFileChooser.