0

I'm working on some Java objects that represent XML elements. Because the standard I'm currently working with can become a bit unwieldy, I'm designing compositions with a number of JAXB objects (generated straight from the .xsd) and providing additional functionality for ease-of-use.

Since the objects that I'm representing in Java are actual XML objects, would it be appropriate to serialize them to XML? If not, why would this be a bad idea (aside from performance reasons)?

EDIT:

I'm getting a number of "why would you even want to do this?" type questions so let me explain a bit. It's often appropriate to consider a custom serialized form when an object's logical implementation is largely different than its physical implementation (from Bloch's Effective Java, item 75). In my case, the physical form will differ significantly from the logical form and a custom serial representation is appropriate. Since the object will ALWAYS be able to be represented by XML, it seems like a good fit logically, but I'm trying to understand the implications of this with the Java language (I.E. performance).

josh-cain
  • 4,997
  • 7
  • 35
  • 55
  • 2
    What do you mean by 'actual XML object'? JAX-B can serialize most java objects. – bmargulies Feb 19 '13 at 13:32
  • This really depends on what you're trying to accomplish... is it needed to meet your business requirement? You don't want to marshal and unmarshal unnecessarily because as you said, it is expensive. – Geoff Feb 19 '13 at 13:38
  • I mean that the java object represents an XML standard. For instance, a SOAP object in Java represents XML - the object should always be able to be expressed by the XML standard it implements. As for the JAXB part, I'm using a composition containing JAXB elements that represent the object correctly. However, the context in which I'm using it requires additional logical checks that JAXB does not provide. – josh-cain Feb 19 '13 at 13:38

4 Answers4

1

i doubt that this is a goid idea. xml representation could needs about 100 times the space that a binary rep would need. before i would use xml doc serialisation i would use java std serialisation. (which is comfortable but not efficient)

better suited would be some binary xml representation. like BSON for JSon or Google protobuf. Look for binary XML.

AlexWien
  • 28,470
  • 6
  • 53
  • 83
0

Since the objects that I'm representing in Java are actual XML objects, would it be appropriate to serialize them to XML?

I assume you mean something like a DOM. And that you then serialize using some XML binding ... treating the DOM objects as POJOs !!

Bad idea, IMO.

If not, why would this be a bad idea (aside from performance reasons)?

  • Serialization and deserialization performance will be bad.
  • The serialized form will be bloated.
  • The generated XML will be unreadable.
  • The serialization will difficult for anything else to process. Consider trying an XSLT transformation on it. Consider trying to process it using an event-based parser.

Actually, I'm struggling to think of any reason that this might be a good idea.

UPDATE

Your explanation (in your updates / comments) as to why doing this are unconvincing:

It's often appropriate to consider a custom serialized form when an object's logical implementation is largely different than its physical implementation (from Bloch's Effective Java, item 75).

Bloch's advice is to consider using a custom representation. And implicit in that is the assumption that you consider a BETTER custom representation than the standard one you have in front of you.

In my case, the physical form will differ significantly from the logical form and a custom serial representation is appropriate.

That doesn't explain why you want to represent the DOM in XML in the first place. Or why you think it is better.

Since the object will ALWAYS be able to be represented by XML, it seems like a good fit logically, ...

You haven't explained that logic.

... but I'm trying to understand the implications of this with the Java language (I.E. performance).

Well the implications are as I explained above. And there is nothing Java specific about this.

OK lets look at this from another perspective.

  1. You have some information.
  2. You represent that information in XML.
  3. You parse the XML to give you an in-memory representation - a DOM.
  4. You apply something like jaxb to give you an XML representation of the DOM ... viewed as POJOS
  5. You serialize the DOM.

What you end up with an XML representation of Java objects that represent some XML that represents your original information.

How is this better than your XML representation of the original information?

Now, maybe, if at step 3 you had used jaxb and deserialized to custom Java classes ... then serializing those Java classes to would make sense. But then you don't have "Java objects that represent XML elements". Rather you have Java objects that represent the information that was represented by your original XML.

That is a COMPLETELY DIFFERENT THING to what you actually wrote in your Question. And if that is what you meant, it explains why people didn't understand you ... and thought what you were actually saying made little / no sense.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • First of all, my objects are POJOs. Secondly, I would serialize and deserialize from and to the representative object so as to include all the logical constraints in the appropriate object. Doing something like deserializing to a different object by a different means is not what I'm after here. The reason I'm curious is because the serialized form exists as a contract - I can be sure that it will ALWAYS be unchanged if I use the representative XML. – josh-cain Feb 19 '13 at 13:48
0

Do you mean serialize to an XML file? The general opinion would be that this is not a good idea for performance reasons, however if you had an intention to use these objects/xml files as a feed to another system then it might be worth considering

farrellmr
  • 1,815
  • 2
  • 15
  • 26
0

If your primary concern is being able to validate that the object against the rules defined in the XSD, this is a link to how that works. Given this, be aware that marshalling the object to XML will cost you some cycles. One of the significant performance hits is creating the JAXB Context that you will use to marshal the object. You can minimize this performance hit by creating a JAXB Context in some kind of singleton object (POJO, Spring bean, etc.) so it won't be re-created every time.

Community
  • 1
  • 1
Geoff
  • 773
  • 1
  • 6
  • 13