I've been spending some time working with the JPDA - Java Platform Debugger Architecture - and it's pretty darn cool. Using this framework, which is shipped with the basic Java SE JDK, basically allows you to write debuggers.

I hear you ask: Why on earth would you want to do this when there are so many good debuggers already? Eclipse does everything I need!

True. But what if you need one process to monitor the execution of another? And I don't mean to have interprocess communication, I mean for one process to MONITOR THE EXECUTION of the other. Sounds like a debugger to me. Why should Eclipse have all the fun?

I've recently been doing a lot of work with getting stack traces for a project I'm working on, and I've had what I sometimes call a "BGO" - Blinding Glimpse of the Obvious: getting Stack Trace information in Java is dead slow.

I ran into a "gotcha" with Hibernate this past week.

I was working with an Oracle database where there are tables with synthetic (aka surrogate) keys that get their values from sequences -- a fairly common thing, and a situation that Hibernate normally handles well with identity generator class of "sequence" or "native".

But in this case, the Oracle database was using a before-insert trigger to get nextval from the sequence and stuff it into the primary key field before inserting the row into the table.  The rationale for this was to ensure consistent management of the sequence for other code than the Hibernate/Java system that might hit the database.

I've started a new (mostly) greenfield project recently and after two years of having to code in an existing application with a restrictive framework, I was eager to stretch my legs a bit and break out some of the good ol' tools that made me so productive in previous gigs - XDoclet being one of them.

For those who don't know, XDoclet is an open-source tool that lets you put special tags in your javadoc, which XDoclet finds in a post- or pre-compile step, and uses to generate more code, or configuration files, or whatever else you want to generate.  Most frequently, XDoclet is used to generate deployment descriptors and helper classes to go with the most important classes of a system.  Hibernate promotes (or at least, promoted) XDoclet as part of its suite of tools for easing configuration. Almost any book on Hibernate includes at least one chapter on using XDoclet to build your Hibernate configurations.

Those of you who know me or who have read my earlier posts know that I am a static code analysis fan, and some of my favorite tools are PMD, Checkstyle, FindBugs, and JDepend, for their excellent feedback on the state of the quality of your code. In fact, I regularly use all of them and usually in combination with other tools (such as JUnit, Emma, etc) to gather code metrics. 

The reports from each of these tools naturally identify problems -- why else would you run them?  And once you see a problem, you naturally want to run right out and fix them.  The report shows them all, rated by severity, with counts and everything, and you can see the types of errors.   It's just a simple refactoring, right?

Better think twice before activating that refactoring in your IDE.

In a previous job, I had a trainer for a CASE tool who gave me a phrase that has stuck with me for the past 15 years: "A fool with a tool is just a faster fool."  The truth of this is obvious on the surface, of course, but many times we developers don't see it happening to us as it happens - the onset is too gradual.  I am beginning to see an emergent anti-pattern, particularly among my less experienced colleagues, which has cropped up as a result of Eclipse usage - something I call "Squiggly-Driven Development". 

While preparing a training class this past month on Effective Exception Handling for a client, I came up with a list of "Ten Commandments of Exception Handling."  Some of them were the basic, standard items ("Thou shalt not catch or throw java.lang.Throwable", "Thou shalt not throw raw java.lang.RuntimeExceptions--thou shalt throw a subclass instead", "Thou shalt not catch an Exception unless thou art going to truly handle it, or are going to wrap it in another Exception").  Other items on the list were specifically tailored for the client.  I liked one of the "commandments" better than the others, however:

"XIII: Thou shalt not catch any Exceptions in JUnit tests, unless testing that your code under test throws the Exceptions the API says it does."

If you have ever needed to produce a diagram of shapes connected by lines -- and what software developer hasn't? -- you've probably thought to yourself "there's got to be a better way to do this" as you open up your graphics editor and start dragging around rectangles and lines.

One tool you owe it to yourself to learning about is Graphviz (www.graphviz.org).  With this tool, you prepare an input text file listing the nodes, and the connections between them, and it produces diagrams for you.  The input files can be as simple as this:

In a previous blog entry I mentioned that I like emma for measuring code coverage in my JUnit test suites.  In this entry I will discuss several items that make some JUnit test suites stronger than others.  In this entry I am discussing JUnit 3.8.1.

How do you measure the quality of your JUnit tests and put a number
on it?  This is a very good question with no quick and easy answers,
I'm afraid. I can tell you two answers that are NOT measures of test quality:

The movie The Untouchables had Robert DeNiro as Al Capone deliver a great line: "You can get a lot further with a kind word and a gun than you can with a kind word."

Now, I'm not promoting the violence, but in the world of corporate computing there will always be times of competing claims. You've seen it. The systems guys will claim your application crashed their database. Another developer will claim that you've broken their code. Your project manager will claim that you should be able to complete a task in a certain amount of time that they've pulled out of thin air. You obviously think differently, but how do you make your case?