Groovy: XML without the bloat
Flexible strings
Customer Success Testimonial: Recovery is Everything
Hands on, part 1 You may find this hard to believe, but there was a time before XML hell, when the idea was that XML was going to solve just about every tricky problem in software development. From swapping data between applications or platforms, to storing complex data structures in a portable format - XML was the answer.
Growing up around the same time as XML was Java, which - like XML - has since gone on to shape an industry. If we’re honest, though, it’s never been an easy relationship between these two. Processing XML in Java is a common enough requirement, but it can be extremely verbose, requiring plenty of boilerplate code and all kinds of extraneous scaffolding that obscures what are often very straightforward functions.
That’s where Groovy comes in. As befits a young scripting language for the Java Virtual Machine, Groovy can do XML in a way that is relatively free of bloat and allows the developer to focus on the real problem at hand. In this two-part tutorial I shall look at how Groovy can help in reading and writing XML documents. You can find instructions on installing and running Groovy here, or you can refer back to my earlier article.
At some time or other we’ve probably all written code that just uses strings to write out a fragment of XML. It’s cheap but clunky, but it saves having to instantiate a DOM tree or any of that fiddly stuff. Groovy’s flexible strings allow us to do this very, very simply.
Here’s how we create a fragment of XML that contains a list of names each in an element called "hello", and each with an order attribute:
names=['john','bill','ted']
x=0
frag=''
names.each {
x++
frag+="""<hello order="$x">$it</hello>\n"""
}
Running this code in the GroovyConsole, or dumping it into a file called xml.groovy and running it from the command line produces the following output:
<hello order="1">john</hello> <hello order="2">bill</hello> <hello order="3">ted</hello>
But that’s only a bunch of strings, there’s no XML declaration, and certainly no way it can be processed as XML. If we do need to turn this into a DOM tree, we can do that easily enough too. Let’s make our hello elements children of a root element called "names" and then turn it into a DOM tree that we can interrogate:
def StringReader s=new StringReader("<names>\n" + frag + "</names>")
def xmldoc=groovy.xml.DOMBuilder.parse(s)
def names=xmldoc.documentElement
println names
use (groovy.xml.dom.DOMCategory){
println names.hello[0].text()
println names.hello.size()
println names.hello[1].attributes.item(0).text()
}
This code spools out our well-formed XML and the results of some simple tree walking:
<?xml version="1.0" encoding="UTF-8"?> <names> <hello order="1">john</hello> <hello order="2">bill</hello> <hello order="3">ted</hello> </names> john 3 2
It should be clear by now that the combination of Groovy’s convenience methods (from the groovy.xml.* libraries), iterators and powerful string handling capabilities make for very succinct code for creating XML from relatively straightforward data. While the equivalent Java code would take a lot more typing - which wouldn’t be half as readable and easy to follow - so far there’s nothing tremendously taxing here.
COMMENTS
@ Niall
The bit about the boss firing the web-head was meant as humor.
I can't claim to have an agenda, but I do have strong preferences, and I am not impartial.
Impartiality and wisdom are not synonymous nor need they even be coincident. So I can be wise as well as partial. And I am wise.
That last bit is also meant to slightly humorous.
Still have not read the article?
Funny I don't remember advocating Java or Groovy, or comparing it with C++, Perl or PHP. Making an argument for or against Java or Groovy is beside the point. If I have a Java application, or if I am developing in a Java environment (clearly the topic of this article) I am not going to consider Perl, PHP, or C++ for processing XML. You obviously have an agenda, and your agenda has nothing do the subject of this article.
"I were to meet some Java programmer who parses XML for pleasure I would not be too surprised."
Ya, thats real impartial.
"If I need gigs of RAM and fast CPUs to execute a VM to do a job (parse XML) that could be done faster in less resources by not using a VM (ie use C++, or PERL, or PHP not Java + Groovy) then I must question the value of the VM, and I can add the VM itself to the quantity of bloat involved in the Java approach."
The "Java approach", nobody is talking about Java as an approach. If you are parsing XML with Java then you are doing it because your application needs to satisfy a goal. If I have a Java application I do not consider C++ or C libraries.
"I have to write according to the odd and crypto-fascist Java type safety system."
Again, your impartial wisdom is enlightening.
"You're fired, you pinko, vacuous, pot smoking wanker."
Do I even need to comment on this?
Niall
@ Niall Gallagher
Plainly one parses XML to satisfy a goal. Although if I were to meet some Java programmer who parses XML for pleasure I would not be too surprised.
>>> We are talking about the JVM as a platform, it is what Groovy and Java use. I refer you to the introduction:...
... and many of the other comments were pointing out that JVM is not a platform but rather a virtual machine running on a (hardware) platform. If I need gigs of RAM and fast CPUs to execute a VM to do a job (parse XML) that could be done faster in less resources by not using a VM (ie use C++, or PERL, or PHP not Java + Groovy) then I must question the value of the VM, and I can add the VM itself to the quantity of bloat involved in the Java approach.
>>> "Processing XML in Java is a common enough requirement, but it can be extremely verbose, requiring plenty of boilerplate code and all kinds of extraneous scaffolding that obscures what are often very straightforward functions"
Well, fine, but you seem to view all the stuff that must be done merely to assemble a JVM system ( = hardware + OS + JVM + app server + perhaps web server + probably CMS + probably DBMS + C/C++ compilers to build all the native machine code libraries any decent Java system requires under the hood + ...) as not part of the verbosity. Compare all that stuff to the non-JVM method ( = less hardware + OS + C/C++ compilers + web server + perhaps PHP or PERL).
They are plainly not equivalent. The JVM approach is bigger, slower, more bloated qua disk & RAM & CPU. And, well, sorry but if I want to do 'X' in Java I need to write a lot more lines of just Java code INCLUDING everything needed to instantiate instantiating a Groovy interpretter, than if I did it in PHP or C++ (I don't actually like or use PERL much), AND I have to write according to the odd and crypto-fascist Java type safety system.
Seriously, man, have you never used something like SAX or a stream parser in C or C++? Just define some callbacks, register them and being processing your data. It's that simple - and there are probably only two acronyms involved, unlike Java.
Finally, the name itself is kind of stupid. "Groovy" is plainly chosen to appeal to web-heads more on it's sound than any particular technical superiority it may (not) have, or any capacity to describe what it actually does:
Wide eyed web-head: "...well, boss, I programmed it in Groovy".
Boss: "You're fired, you pinko, vacuous, pot smoking wanker."
Just wanted to make my point more clear.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
