Parsing XML with Java 1.4.2 own tools?

[Donkey Hottie]

So I have written own code which writes XML.

Now I need to read and unmarshall it back to Java objects. Writing XML is
not hard, but reading it without SAX or DOM seems too much done when there
is old and good solutions.

But it seems that org.xml.sax.*, org.w3c.dom.* and javax.xml.* all define
only interfaces for parser, and they rely on Apache Xerces or another 3rd
party parser.

My boss does not want Open Source, and propably is not willing to pay for a
3rd party parser.

How to parse.... without Open Source or rolling my own..

 

[John B. Matthews]

So I have written own code which writes XML.

Now I need to read and unmarshall it back to Java objects. Writing
XML is not hard, but reading it without SAX or DOM seems too much
done when there is old and good solutions.

But it seems that org.xml.sax.*,org.w3c.dom.* and javax.xml.* all
define only interfaces for parser, and they rely on Apache Xerces or
another 3rd party parser.

My 1.4.2 has those classes, and it seems to parse & transform OK. Sorry
if I'm overlooking something:

$ jar tf [...]/Versions/1.4.2/Classes/classes.jar | grep org.xml.sax
org/xml/sax/AttributeList.class
org/xml/sax/Attributes.class
org/xml/sax/ContentHandler.class
org/xml/sax/DTDHandler.class
....

They appear to be from OASIS.

My boss does not want Open Source, and propably is not willing to pay
for a 3rd party parser.

Your boss may already be a licensee. IANAL. YMMV.

 

[Donkey Hottie]

Aside from the fact that your boss is an idiot, Java 1.4.2 *does*
include the ability to parse without *any* third party tools. Look
again at the API Javadocs.

Pay particular attention to the javax.xml.parsers package, where
you'll find the DocumentBuilderFactory that can provide instances of
the DocumentBuilder class. While its name suggests that it builds (as
in creates new) documents, it also parses from existing data. That
is, it "builds" documents by parsing XML.

But but.. as I was talking about abstract classes and interfaces...

javax.xml.parsers.DocumentBuilderFactory IS an abstract class. API doc does
not tell about classes extending it!

javax.xml.parsers.DocumentBuilder is an abstract class as well.

I can't see any implementations in the API doc.

 

[Mike Schilling]

But but.. as I was talking about abstract classes and interfaces...

javax.xml.parsers.DocumentBuilderFactory IS an abstract class. API
doc does not tell about classes extending it!

Yup. But you can instantiate some concrete subclass of it using
DocumentBuilderFactory .newInstance(). There's an elaborate
mechanism for determining which concrete subclass that is (see
http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/parsers/DocumentBuilderFactory.html#newInstance() )
, but for simple parsing of reasonably-sized documents, whichever you
get will be fine.

Having gotten your DocumentBuilderFactory , you can configure it with
the setXXX() methods, create DoucmentBuilders from it, and start
parsing things.

 

[Mike Schilling]

Aside from the fact that your boss is an idiot,

Not necessarily. If you're building a commercial product, including
open source code means that you have to worry about its licensing.
GPL, for instance, is simply unusable. Apachae is much friendlier,
but there is still some work to do to be compliant with it. If your
customers are going to repackage or OEM your work, you're given them
that same burden and you've guaranteed that you'll have to deal with
their legal department. Believe me, there's nothing quite like
learning after you thought you'd made a sale that customer A doesn't
like the license for open source library B, so you'd better either
find a replacement they do like or implement it yourself on a deadline
imposed by your sales department.

 

[Thomas Kellerer]

Donkey Hottie wrote on 12.09.2008 20:34:

So I have written own code which writes XML.

Now I need to read and unmarshall it back to Java objects. Writing XML is
not hard, but reading it without SAX or DOM seems too much done when there
is old and good solutions.

If your Java objects are standard Beans (i.e. with a default constructor and
relevant setter/getter methods) you can use the XMLDecoder and XMLEncoder to
read and write Java Beans.

Might be a lot easier than writing your own marshaling/unmarshaling stuff as
long as you can live with the XML format generated by the JDK

Writing a bean boils down to:

OutputStream out = new FileOutputStream(filename);
XMLEncoder e = new XMLEncoder(out);
e.writeObject(someBean);
e.close();


Reading is just as simple:

InputStream in = new FileInputStream(filename);
XMLDecoder e = new XMLDecoder(in);
Object result = e.readObject();
e.close();


Regards
Thomas

 

[Donkey Hottie]

Donkey Hottie wrote on 12.09.2008 20:34:

If your Java objects are standard Beans (i.e. with a default
constructor and relevant setter/getter methods) you can use the
XMLDecoder and XMLEncoder to read and write Java Beans.

Might be a lot easier than writing your own marshaling/unmarshaling
stuff as long as you can live with the XML format generated by the JDK

Writing a bean boils down to:

OutputStream out = new FileOutputStream(filename);
XMLEncoder e = new XMLEncoder(out);
e.writeObject(someBean);
e.close();


Reading is just as simple:

InputStream in = new FileInputStream(filename);
XMLDecoder e = new XMLDecoder(in);
Object result = e.readObject();
e.close();


Regards
Thomas

Thanks, this seems promising!

 

[Chris Riesbeck]

Thanks, this seems promising!

I used this approach for persisting a couple hundred business rule
objects. I wouldn't recommend it for 1000's of objects, because of the
read/write time, but it was very simple and robust. You do have to make
sure everything to be persisted implements java.io.Serializable, which
is usually trivial.

 

[EJP]

You do have to make
sure everything to be persisted implements java.io.Serializable, which
is usually trivial.

No you don't. XMLEncoder has nothing to do with Serializable.

 

[Roedy Green]

My boss does not want Open Source, and propably is not willing to pay for a
3rd party parser

What is the other possibility?

 

[Mike Schilling]

What is the other possibility?

Use the parser that's built into the JRE.

 

[Donkey Hottie]

Use the parser that's built into the JRE.

I just today found out that J2ee.jar (at least in an old JBoss) contains
Apache Crimson. That will do. I guess is the Sun's reference
implementation for 1.4.2.

 

[Mike Schilling]

I just today found out that J2ee.jar (at least in an old JBoss)
contains Apache Crimson. That will do. I guess is the Sun's reference
implementation for 1.4.2.

You don't need J2EE to have an XML parser. J2SE 1.4.2 also contains
Crimson.

 

[Lew]

I just today found out that J2ee.jar [sic] (at least in an old JBoss)
contains Apache Crimson. That will do. I guess is the Sun's reference
implementation for 1.4.2.

You don't need J2EE to have an XML parser. J2SE 1.4.2 also contains
Crimson.

.... as Ignatius W. Pavlov obligated in this energy on 12 September.

If memory serves, the Sun 1.4.2 implementation used Crimson. You might
squelch your boss and his opposition to quality third party open source
software by pointing out that, as of 1.5 (aka Java 5), Sun's own
reference implementation now includes Apache's Xerces.

--
Lew


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Every time we do something you tell me America will do this
and will do that . . . I want to tell you something very clear:

Don't worry about American pressure on Israel.
We, the Jewish people,
control America, and the Americans know it."

--- Israeli Prime Minister,
Ariel Sharon, October 3, 2001.