Discussions

News: Simple 2.0 - Version Tolerant XML Serialization

  1. The Simple XML serialization framework has released version 2.0. Simple is is a version tolerant serialization framework for Java that enables rapid development with XML on the Java platform. The framework used to provide XML serialization is simple to use and revolves around several annotations an a single persister object used to read and write objects to and from XML. Both serialization and deserialization are fully supported. Features include.
    • Fully configurable XML structure defined via annotations, converts to and from concise human editable XML
    • Version capable framework allows both forward and backward compatible serialization
    • Highly performant, using lightweight StAX to perform the XML deserialization process, faster than XStream and JAXB
    • Full namespace support provided via namespace annotations
    • Contains an XML templating system to allow expressions to be evaluated and substituted
    • Provides persister callbacks to allow validation and interception of deserialization
    • Fully self contained, other than StAX there are no external dependencies
    • Open source, released under the terms of LGPL
    Home: http://simple.sourceforge.net/ Documentation: http://simple.sourceforge.net/download/stream/doc/javadoc/ Tutorial: http://simple.sourceforge.net/download/stream/doc/tutorial/tutorial.php

    Threaded Messages (17)

  2. Version capable framework allows both forward and backward compatible serialization
    What does that mean?
  3. Hi, What it means is that you are able to read older versions of an XML document with a versioned XML schema class. So for example, if I did the following: @Root @Namespace(prefix="p", reference="http://www.domain.com/person") public class Person { @Attribute private String name; @Element private String height; @Element private String weight; ... } Having used this class schema to serialize instances of the Person class, I could later extend or modify the class as follows and still read and write in a format compatible with the old class schema like so, even though the resulting XML has changed. @Root @Namespace(prefix="p", reference="http://www.domain.com/person") public class Person { @Version(revision=1.1) private double version; @Attribute private String name; @Attribute private int age; @Element private int height; ... } This is quite similar to the C# XML serialization version capability. Where the initial version of each class is 1.0 (implicitly) and subsequent versions increase. This tells the serializer how it should approach deserialization of different versions.
  4. Looks neat[ Go to top ]

    I just had a cursory look at the tutorial you had - so pardon if I didnt look close enough. My question is we dont need the step where we generate classes from schema files? like we used to do in the case of JAXB or XMLBeans? That has always troubled me a lot since why two sets of Java classes for one xml document? - one generated class for xmlbeans to unmarshall and another written by me to take out the values from xmlbeans' class into mine. If this is true I will really think about moving to Simple in our project. Please let me know. Thanks
  5. Re: Looks neat[ Go to top ]

    Hi, yes. There is no need for these extra steps. Just annotate your objects and read and write them with a persister instance. There is only one artifact, a single annotated POJO.
  6. Hello Pichairaj, It seems like Simple XML and JAXB serve two very different purposes. I think the purpose of JAXB is to catch errors in XML handling at the compiler phase. Simple XML looks very interesting when you have a very stable schema and good unit test coverage. However, if a co-worker changed your schema, renaming a key field (for example), you wouldn't find it till your unit tests broke...or the app was actually deployed (more likely as most projects I've seen either have poor test coverage or don't enforce the running of tests as part of the build). If you used JAXB, you'd never make it past compilation if your schema changed and no one updated the Java handling it. I see JAXB as better when you deal with many complex schemas that evolve over time. This seems like the ideal for simple XML documents (I guess that's why they named it that way) as it looks very easy to work with and seems to leave really clean code. I'm just guessing here, but it also seems to be very useful if you're only interested in a subset of your XML document. For example, if you parsed web.xml and only wanted the servlet declarations, your Simple XML code would be much cleaner and hopefully run much faster than a JAXB version.
  7. Correct, both are quite different. Apart from the ability to annotate objects in order to specify an XML document structure there are fundamental differences. I would summarize it as such, Simple is more of a Java first approach and JAXB is more of an XML/XSD first approach. Simple provides a means to serialize arbitrarily large object graphs to a tailored XML structure, much like Java object serialization but with XML (and of course annotations). Just as the JAXB and other XSD driven frameworks can alert to problems at compile time, this also makes them poor candiates for representing complex polymorphic object graphs. They are just too constrained and will almost certainly make backward compatibliy issues much more difficult to deal with.
  8. Yes[ Go to top ]

    that part I agree - they are different. You will definitely want to use xmlbeans or JAXB when receiving xml docs from a different system. I was thinking more in terms of internal xmls. Thanks for pointing that out!
  9. Re: Yes[ Go to top ]

    You will definitely want to use xmlbeans or JAXB when receiving xml docs from a different system.
    Also XMLBeans supports tolerant XML serialization.
  10. Re: Yes[ Go to top ]

    Well, thats not neccesarily the case. You can use anything from XStream, Castor, JIBX or Simple. JAXB and XMLBeans are popular, and thats what makes them popular. It does not make them better. I think Simple will give you the quickest turn around by far, particularly if you already have your domain objects and you want to persist them to a structured human readable XML format.
  11. Now it works.[ Go to top ]

    Finally it can work with maps and, therefore, usable. I will clearly look at it in my next protocol implementation.
  12. Hello All, I have an XML-heavy project coming up. Simple XML looks easy enough to use. How is its performance? I have a project in which I'm frequently processing small XML documents with a pretty simple schema. An older implementation was done in JAXB, but JAXB really killed the performance and the JAXB code was always the major hotspot whenever the app was profiled. Simple XML looks like it'll make my code much more readable than if I wrote something in DOM. Is Simple XML 2.0 more performant than JAXB? Has anyone done any benchmarks comparing various Simple XML to the other XML processing frameworks, like JDK DOM/SAX, JAXB, AXIOM, etc?
  13. Hi, This all depends on the types you are transforming from XML. Your not going to beat raw StAX or SAX unless you require conversion of the parsed types to primitives or utility types such as Date, Locale, Calendar and so on. What you will get is a much simpler and more coherent object model when using Simple, as it will allow you to annotate your POJOs as you write them. Simple is particularly good at dealing with very complex object graphs as it localizes the XML structure to the class it is dealing with. On measurements I have performed Simple was faster than JAXB at deserialization and about the same on serialization. However, simple is much more flexible and can deal with polymorphic types transpaently.
  14. Tooling?[ Go to top ]

    Are there tools like xjc for jaxb available that will take a xsd and create the annotated POJOs from it? Usually i have to deal with complex schema with hundreds of complex types and creating POJOs by hand becomes a very tedious operation
  15. Re: Tooling?[ Go to top ]

    Currently there is no tooling available, I plan to introduce some shortly. But for now it requires annotating existing POJOs. Although the benefits are obvious I am personally not a fan of generated code. I prefer to annotate an existing coherent object model, which can then be serialized and deserialized as XML.
  16. Re: Tooling?[ Go to top ]

    An advantage of annotating existing POJOs rather than using code generated is than annotated objects tend to survive refactors without breaking compatibility. I personally know from experience that code refactors and changes to the XML format can break easily compatibility with frameworks like JAXB and transformers as used in XStream.
  17. binary xml (fast infoset)[ Go to top ]

    Hi, Does it support binary XML serialization? I've just tried JAXB2 + Fast Infoset today with really good performance (even compared to Java Serialization) and I'd be interested how Simple compares to that. Thanks, Istvan
  18. JSON extension[ Go to top ]

    Hi, Are you planning to include an JSON serialization/deserialization facility in a future?. It would be also an incredible useful extension to simple, specially for its use in REST scenarios.