Save Time Fixing Ant Errors With -verbose Switch

Resolving ant errors can be a pain sometimes because of the vague error messages you get on the console. Yesterday I was getting a "Process fork failed." error on my Junit task and all I got on the console was

BUILD FAILED
C:\work\builds\build.xml:58: Process fork failed.

I wasted a couple of hours on google looking for an answer and after failing to fix the issue with several suggested solutions, I stumbled upon one post that suggested enabling the verbose output of Ant. All you had to do was pass -verbose as a command line parameter to ant

ant -verbose <target>

That made ant display lot of details including the actual exception. In my case it was:

C:\work\build\build.xml:58: Process fork failed.
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:871)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:679)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1413)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:633)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
Caused by: java.io.IOException: CreateProcess: C:\bea92\jdk150_04\jre\bin\java.exe ...


I found the issue a little bit above the exception on the console and it was the massive classpath value passed into the java.exe. Obviously the Windows command line has a limitation on the length of command line arguments and the value for classpath was exceeding it.

When I checked the build file I found the error, where it was adding the files in a directory instead of the directory into the classpath. Fixed that small error and all was fine again.

Anyway glad I got to know about the verbose switch in Ant and hopefully I wouldn't have to waste a lot of time again fixing ant issues again.

Why would anyone want to buy a commercial JDBC driver?

In all the projects that I worked on over the last 5 to 6 years, nobody even thought about using a commercial JDBC driver. When I started on J2EE development you had to buy a JDBC driver for MS SQL server. This was around 2000-2001 when Microsoft didn't have an implementation.

We bought a driver from i-net software (Opta if I remember correctly) which I guess was the best commercial driver available at that time. Later on the application was ported to Oracle and we were happy to use the Oracle thin driver instead of bothering to buy another commercial implementation.

Since then I have worked for several big enterprise clients, developing Java web applications that connected to Oracle, MS SQL Server and DB2 (ver 7.2) databases. All these applications were using the database vendor provided drivers and all was well except for the DB2 driver (net driver).

I used to visit i-net software web site frequently as their Crystal Clear reporting tool was used in some earlier projects. Today I stumbled upon their site again after a long time and I started wondering why no one even considers using commercial drivers anymore including myself.

I could think up of a few possible reasons to shell out few bucks for a JDBC driver.

1. Performance
2. Reliability
3. Available features (JDBC 3.0, XA support etc...)

Now if we take Oracle thin driver and the above list, I don't see how a third party driver can provide significant performance and reliability over the thin driver.

As for features, thin driver has every thing you would need on an average project. Commercial implementations usually have few additional bells and whistles (e.g. i-net Opta driver supports SSL encryption and implements JDBC 4.0 API) which usually are not that important.

I guess same could be said for the SQL Server drivers from Microsoft and hopefully the new DB2 drivers from IBM, that is they does the job for your average project.

Also given the fact that application servers like BEA Weblogic includes its own drivers for all major databases including SQL Server, DB2, Sybase and Informix, I really don't see a reason to buy a JDBC driver from a third party.

Having said that, I would love to know about instances where a commercial driver was used and the reasons behind it.

P.S. Elaborating on the issue with the older DB2 driver:

DB2 v7.2 didn't come with a type 4 JDBC driver and we had to use what was called the net driver. There was this funny problem where it failed to see some records in a table. Select queries would not return these records when connected through the net driver. We never figured out why and only solution was to delete the record and insert them back. Luckily for us it only happened in the QA server :). Anyhoo the database was upgraded to DB2 version 8 and the driver to the type 4 version that came with it.