Fixed the regular expression to check for more strict requirements.

With Java Web Start 1.5.0 all of a sudden new proxy properties were introduced (deployment.proxy.http.host, deployment.proxy.http.port and deployment.proxy.bypass.list) valid only for the webstart environment - and if that was not enough yet, it does not support the existing proxy properties, neither the standard, nor the deprecated ones from old Java releases. To topple even that, for the bypass-list the delimiters were changed to semicolon (http.nonProxyHosts has the pipe char as delimiter) ...

standard networking properties

the workaround here makes sure, that if any one of these proxy properties (deprecated, standard or webstart-5 ones) are set, that all the others get the same settings - this pays off, if you're using different third-party components relying on one specific set of these proxy properties (especially if it's beyond your power, in what kind of environment the software will be executed respectively integrated...)

if you use the same buildfiles on your local codebase and your continuous integration buildserver, the if-attribute for ant's targets comes in handy...

for this ant buildfile snippet to only create+publish javadoc when executed on the buildserver, the buildserver only has to set the referred system property, e.g. on its startup by using a Java D-option "-Dcontinuous.build=true" ...

ant buildtool website

Java properties files can yield undesirable results at runtime, if there happen to be spaces at the end of some lines.

Requires a win32 port for the GNU utilities grep and sed - e.g. http://unxutils.sourceforge.net/.

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.

Another way to generate a unique ID.

Reading and writing to a URL connection, thanks to Java.

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:

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));

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.