Mike just posted what appears to be a

death sentence for the Groovy project, and it was a very sad read for me
because while I like Groovy so much, I can’t do anything else but agree with his
assessment.

First of all, please note that Mike put money where his mouth is:  since
his

previous rant on Groovy about a month ago, he has been very active on the
Groovy mailing-list and he has tried hard to piece together a decent set of
documentation for Groovy Classic.  I suppose that his post today is the
observation that this effort failed and the confirmation of his worst fears
about the future of Groovy.

But you know what, James?  There is still hope.  There is one very
simple way you can prove Mike and countless other disillusioned Groovy fans
wrong about their fears:

Announce a date by which you will ship Groovy 1.0

It’s that simple.  Really.  Everything else will fall into place.

Once you have a ship date, you will start looking at your work on Groovy very
differently.  Everything will become a matter of compromises between the
importance of the feature and the necessity to hit the deadline.  The
roadmap will also appear to you much more clearly, starting backwards: 
plan a beta one month before the deadline, an alpha two months before, a few
milestones here and there (not indispensable but I’ve found that milestones keep
you honest and give you a good idea of your velocity).  You will also be to
make the best use of the various volunteers who offer their help.

Alright James, it’s your turn now.  Pick a date.  Any date.

Groovy deserves it.

There are numerous ways to parse XML in Java but they are all based on one of
the two technologies:

• DOM
• SAX

I’m not going to explain what these two API’s do exactly, there are plenty of
articles on the subject, but in a nutshell, DOM gives you a tree view of your
XML document, which you can then navigate by moving from one node to the other,
while SAX is event-driven and will call your code whenever it encounters a tag.

Over the years, I have come to developa strong liking for SAX despite its
apparent limitations, and now, it’s reached a point where I haven’t needed to
resort to DOM for a long time, and here is why.

The thing I like most about SAX is that it allows you to ignore all the
portions of your XML document that you don’t care about, making it not only
trivial to only pick the information you are interested in, but also easier to
migrate your schema over time, should you decide to do so.

Consider the following XML document:

<person>
  <first-name value="Cedric"</first-name>
  <last-name value="Beust"</last-name>
</person>

Extracting the first and last names is straightforward:

 public void startElement(String uri, String localName, String qName,
Attributes attributes)
    throws SAXException
  {
    String name = attributes.getValue("value");
    if ("first-name".equals(qName)) {
      System.out.println("First name:" + name);
    }
    else if ("last-name".equals(qName)) {
      System.out.println("Last name:" + name);
    }
}

Note that the code above is completely ignoring the <person> tag and it focuses
exclusively on the content we are interested in.  If we have reached this
point in the code (which is defined in a ContentHandler), the parser has
probably already verified the validity and well-formedness of your
document.

Of course, this code won’t work if the same tags appear several times in the
document:

<project name="TestNG">
  <members>
    <person>
      <first-name value="Cedric"</first-name>
      <last-name value="Beust"</last-name>
    </person>
    <person>
      <first-name value="Alexandru"</first-name>
      <last-name value="Popescu"</last-name>
    </person>
  </members>
</project>

or, even more tricky, if these tags have different parents:

<project name="TestNG">
  <members>
    <vampire-slayer>
      <first-name value="Buffy"</first-name>
      <last-name value="Sommers"</last-name>
    </vampire-slayer>
    <vampire>
      <first-name value="Angel"</first-name>
      <last-name value="Angelus"</last-name>
    </vampire>
  </members>
</project>

A typical way to solve this is to keep track of the parent tag:

private VampireSlayer m_vampireSlayer = null;
private Vampire m_vampire = null;

 public void startElement(String uri, String localName, String qName, Attributes attributes)
    throws SAXException
  {
    String name = attributes.getValue("value");
    if ("vampire-slayer".equals(qName)) {
      m_vampireSlayer = new VampireSlayer();
    }
    else if ("first-name".equals(qName)) {
      if (null != m_vampireSlayer) {
        m_vampireSlayer.setFirstName(name);
      }
      else if (null != m_vampire) {
        m_vampire.setFirstName(name);
      }
    }
// …

Don’t forget to "pop out the context" when you exit the tag:

 public void endElement(String uri, String localName, String qName)
    throws SAXException
  {
    if("vampire".equals(qName)) {
      // store the vampire somewhere
      m_vampire = null;
    }
    eles if("vampire-slayer".equals(qName)) {
      // store the vampire slayer somewhere, then
      m_vampireSlayer = null;
    }

However, the problem with this approach is that the business logic attached
to a certain tag is now scattered in two different places, which makes the
code hard to maintain, so I have adopted the following rule:  whenever I
need to run code both at the start and at the end of a tag, I move the business
logic in a method that takes a boolean indicating if we are opening or closing
the tag:

 public void startElement(String uri, String localName, String qName,
Attributes attributes)
    throws SAXException
  {
    String name = attributes.getValue("value");
    if ("vampire-slayer".equals(qName)) {
      xmlVampireSlayer(true /* start */);
    }
// …

 public void endElement(String uri, String localName, String qName)
    throws SAXException
  {
    if("vampire-slayer".equals(qName)) {
      xmlVampireSlayer(false /* start */);
    }
// …

  /**
   * @param start If true, we are looking at a opening tag (e.g. <foo>),
   * otherwise, we are looking at a closing tag (</foo>)
   */
  private void xmlVampireSlayer(boolean start) {
    if (start) {
      m_vampireSlayer = new VampireSlayer();
    }
    else {
      // store the vampire slayer somewhere, then
      m_vampireSlayer = null;
    }
  }

And now we have the
best of both worlds: code that is not only easier to read but also quite robust
in the fact of schema changes.

Now, imagine a more complex situation where
your XML file can have tags nested six or seven levels deep.  One day, you
need to add a new tag.  With DOM, you would have to locate the code that is
walking this particular area of the tree, and even with typed tree-based
solutions such as XMLBeans, locating and modifying code is never easy.

With SAX, all you need to do is two things:

• See if the name of this tag is unique within your file (if not, you will
  need to disambiguate it with the context approach shown above).
• Implemt the method xmlTagName(boolean start) and gather its treatment
  inside.

How about you?  Do you prefer DOM over SAX?  Have you encountered
situations where DOM was a much better fit than SAX?

This post brings up a few interesting comments about XML:

XML seems to me overhyped. it is *just* a container for data structuring it
in most cases.

Saying that XML is overhyped is a bit like saying that text files are
overhyped.  The thing is, before XML became a standard, we had a flurry of
text formats used to contain various external information that programs need
(take a look at sendmail.cf or the hundreds of different configuration files
used by any UNIX installation for example).  You never knew what to expect
if you tried to read or edit one.

At least, XML gave us a suite of tools that make editing and reading such
files easier.  It also gave us a wealth of API’s in all languages to avoid
reinventing your own parser, another Good Thing.

In that same comment, Klaus adds:

Besides that it is in fact *not really* human-editable.

… and this I fully agree with.  This is a message I have been pushing for
years but I’ve had a very hard time convincing people.  My
early dislike for XML as an editable format was what prompted me to create EJBGen in the first place, which was one of the very early tools that used
annotations to replace XML (EJBGen started in
early 2001, and its immediate success
showed that I was not the only one having a problem with XML as an editable
format).

It is pretty obvious to me now that as soon as you are creating more than
just a toy program and that your code needs to store data outside the code, XML
is the only sane way to go.

So the question is not really "Why is TestNG using XML?" but "Why is TestNG
using an external file to configure its tests?", as opposed to JUnit where this
is done in code.

The answer is that I make a clear distinction between the static (the
business logic) and the dyamic (what tests are being run) part of your tests. 
I believe JUnit makes the mistake of conflating the two, which forces you to
recompile your code when you decide to run a different set of tests.

If you picture a team of ten programmers, each of them will want to run a
different set of tests as part of their day, and all the time spent recompiling
their test suites is a waste of time.  Not mentioning that they are
modifying code that they need to remember not to submit to the source control
system, since it only runs a subset of all the tests.

Filippo Diotalevi has just posted an
article
on TestNG on DeveloperWorks.  It’s fairly short but gives a very good
overview of the features of the framework.