Part III Finale: A SQLJ MAGIC SHOW @ JDJ

Several fun and important secrets of SQLJ will be unlocked today. Our show will include the following numbers:

• Some magic tricks for taming the SQLJ translator to do your bidding.
• Some incantations to turn you into a SQLJ debug-mon.
• An initiation to the mysteries of execution contexts - for getting full control over executing SQL statements - and of connection contexts.
• A happy story of brotherly love between JDBC and SQLJ.
• A map of the hidden location containing all of the remaining SQLJ details that the wonderful folks from Java Developer's Journal neither would or could let me fit into this column.

Little space and much to say - let's get started right away!

Your Own Private Translator...Is Talking Back
Don't fret if you're stuck and need help - the SQLJ translator may just be able to give you what you need. Enjoy the following translator command-line options:

• sqlj -help shows a short help message with the important SQLJ command line options. And when you just say sqlj by itself this is also recognized as a cry for help.

The Translator-Chameleon Is Serving Up Bugs
How I wish that SQLJ translation were built into the javac Java compiler. But tough luck - it ain't! The translator strives hard to make it appear however as if the only difference is saying sqlj instead of javac.

Nice: You can freely mix .sqlj and .java source files on the command line. The translator also has some implicit make capability similar to javac. Oh yes, it automatically invokes your Java compiler - but you already knew that! Nice: The translator reports error messages from your Java compiler on the original SQLJ file and not on the generated Java file. Not Nice: When your program throws exceptions at runtime, line numbers - such as those issued by printStackTrace() - are shown in terms of the generated Java files.

Incantation #1

Add the flag -linemap to your command line during translation. Then the translator will fix up file names and the line numbers in those class files to show the original SQLJ files. If you want this on by default (which it probably should have been in the first place), then create an environment variable SQLJ_OPTIONS with the value "-linemap". Or you can add the line sqlj.linemap to a sqlj.properties file.

Still Not Nice: If you use Sun's Java debugger jdb to debug your SQLJ program, you'll see that...this tip does not work: jdb refuses to show the SQLJ source. No wonder — they only taught it about .java source files!

Magic spell #2

Shout -jdblinemap instead of -linemap whenever you must trick that silly little (de)bugger.

God Mode: Well, not quite...You can trace the goings-on in the SQLJ runtime by installing a profile auditor in your SQLJ profile files (remember those pesky little .ser files that hold the static SQL information of your program). After the usual translation and compilation you add tracing with the following command: sqlj -P-debug *.ser Have fun drinking from the fire hose!

More Dizzying Debugging Spells
Remember the JDBC Genie? On many platforms (such as Oracle's), SQLJ runtime calls turn into calls to JDBC at the end of the day. You can trace JDBC calls with DriverManager.setLogStream() (or setLogWriter).