Groovy: XML without the bloat

Bleah

Hi.

CFML - the scripting language of the ColdFusion app sever - never gets taken seriously as far as programming languages go, and often for good reason.

But this "Groovy" stuff seems like an awful lot of horsing around compared with CFML's <cfxml> tag (http://tinyurl.com/2mg4dk).

One of those rare occasions where CFML's tag-base`d-ness might actually be the sensible approach.

--

Adam

tricked by the headline

And there i was hoping this article would be about a structured storage format less bloated than XML (TIFF, binary markup etc). But XML+Java+Scripting, and you call that "without the bloat"? It's bloat cubed! (OK admittedly you probably understand bloat as a function of "end developer" code lines while i was thinking about CPU/RAM/storage use)

Reading between Coded Lines ..... Semantic Analysis?

"But XML+Java+Scripting, and you call that "without the bloat"? It's bloat cubed!"

Actually it would/could also be Bloat Application ...Software as a Service [SaaS]..... which could also, well applied, cube results.

Flexible Strings are Real Groovy for they allow for Tangential Growth/Spin Offs........ Innnovative Future Codes/Applications/Systems.

Nice article, Pan.

An even simpler less bloated way

This approach to XML processing could never scale. If you wanted to process XML with either Groovy or Java you should use something like Simple XML Serialization. It requires even less boilerplate code than the example provided in this article. For instance take the example given:

<?xml version="1.0" encoding="UTF-8"?>

<names>

<hello order="1">john</hello>

<hello order="2">bill</hello>

<hello order="3">ted</hello>

</names>

This could be processed with all types converted with the following code.

@Root

public class Example {

@ElementList

private List<Hello> names;

public List<Hello> getNames() {

return names;

}

}

@Root

public class Hello {

@Attribute

private int order;

@Text

private String text;

}

Example example = new Persister().read(Example.class, sourceFile);

This is far simpler and far safer. It can be used with Java and Groovy. The Simple XML Serialization project can be found at:

http://simple.sourceforge.net

Also, it has a really small footprint, and requires only StaX. So if you using Java 6 you do not need anything else, just a single self contained JAR. Finally, for Java based projects, if you did decide to use the Groovy approach you would need all the Groovy dependancies to do XML processing as described in this article, and there are loads.

Niall

Still too verbose

I dunno, people, you can do all that parsing with SAX or several other C++ libraries and have fewer lines of code that run faster. The examples given still have that ridiculous Java-got-a-factory-for-everything BS.

As for scaffolding and infrastructure, well, now you'll have an entire Java VM, to run an interpretter, to parse what is really simple formatted ASCII text. If you're too weak for C++, then PERL or PHP can do the job in approx 10% the resource requirement of Java et al.

Just my $0.02.

Please read the article

You do not parse XML to parse XML, you do it to satisfy a goal, to achieve something. A Java application will parse XML in a JVM, a Perl application within a perl interpreter, and PHP with a PHP interpreter. We are talking about the JVM as a platform, it is what Groovy and Java use. I refer you to the introduction:

"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"

This describes the article and what is being discussed.

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.

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

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.