Simple 1.2 - Java XML Serialization

Discussions

News: Simple 1.2 - Java XML Serialization

  1. Simple 1.2 - Java XML Serialization (27 messages)

    The Simple XML serialization framework has released version 1.2. Simple is is a serialization framework for Java that enables rapid development of XML configuration and communication systems. Its goal is to provide an XML serialization framework that requires no configuration or mappings to serialize objects to and from human readable XML. Below is a list of some of the capabilities of the framework.
    • Simple framework with powerful capabilities 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.
    • It requires absolutely no configuration Unlike many of the XML frameworks for Java there are no mappings or configuration required to serialize objects regardless of its complexity, not even code to establish mappings. Everything is done at runtime, only annotations are required to perform the object to XML structure. The XML schema is represented using field and method annotations.
    • Converts to and from human editable XML A primary goal for the framework is that the XML data used to deserialize and serialize objects is human readable. All XML elements and attributes take a simple structure that can be easily created with a text editor. Also the serialization format is compatible with the C# XML serialization format.
    • Contains an XML templating system As part of the deserialization process template markers within the XML elements and attributes can be replaced with variables. This allows the system to be easily adapted for use as a configuration system with dynamic value substitution. Stock template filers include OS environment variable substitution, system properties, as well as an API that enables custom filters to be introduced.
    • Provides persister callback methods During serialization and deserialization an object can recieve persister callbacks, to validate and prepare data during the process. Each callback allows the object to manipulate the persistance session, which allows values to be passed in to and out of the templating engine, and allows arbitrary attributes to be passed between the persisable objects.
    • Allows XML to drive composition The serialization and deserialization process is controlled by an exensible strategy API, which allows objects to be created based on custom XML attributes. This allows interception of the object creation in order to delegate instantiation to object factories.
    • Fully self contained For Java 6 the framework has no external dependancies and is completely self contained. For Java 5 two external JAR files are required, the StAX API and the StAX implementation, both are provided with the download.
    • Open source Released under the LGPL and so can be fully integrated or adapted for both commercial and open source projects.

    Threaded Messages (27)

  2. No configuration?[ Go to top ]

    Introduction looks fine. But it is funny that "absolutely no configuration" declared - code should be annotated, this is kind of configuration anyway, useful for simple things but not flexible of course.
  3. Re: No configuration?[ Go to top ]

    Annotating the class fields and methods establishes a schema. Are you telling me C# XML serialization, JAXB 2.0 reflection, JPA annotations and other such schema definitions are inflexible. For any serialization system strict mappings are essential. XML tools that require configuration for mappings are error prone and tightly coupled. Also, just to mention the name 'Simple' refers to use not scope.
  4. Re: No configuration?[ Go to top ]

    Are you telling me JPA annotations are inflexible.
    Yes (in this example) in that people shouldnt in the vast majority of situations be defining JPA ORM information in their classes since the target environment is an RDBMS and people would have to edit classes and recompile if they ever wanted to redeploy their class onto a different datastore. For that reason one of the spec owners has even said the same. As always annotations should only be used where applicable, rather than the current tendency to overuse. Whether they are in your use-case I've no idea - it would be for your users to expound their use-case situations which would define if "configuration" is desirable.
  5. simple vs xstream?[ Go to top ]

    is it any better than XStream ( http://xstream.codehaus.org/ )? or more eloquently: for what kind of tasks would you recommend Simple over XStream?
  6. Re: simple vs xstream?[ Go to top ]

    Firstly I think XStream is a cool tool for performing serialization. However I feel that the XML format it uses is not very readable as it has poor attribute support. It makes it less attractive to use for configuration purposes. Also, XStream tends to make use of mapping code over annotations, which I am not a fan of. I feel this form of mapping is ugly and fragile, it also takes longer to code and does not have great reuse. With the Simple API you write your objects and plug them together in fields and methods, every thing can be reused. Finally, although the focus of XStream is serialization, which I feel it does well it is not easily adapted for other uses such as configuration systems. Simple allows you to create template variables which can be manipulated via a serialization session.
  7. Re: simple vs xstream?[ Go to top ]

    Firstly I think XStream is a cool tool for performing serialization. However I feel that the XML format it uses is not very readable as it has poor attribute support. It makes it less attractive to use for configuration purposes. Also, XStream tends to make use of mapping code over annotations, which I am not a fan of. I feel this form of mapping is ugly and fragile, it also takes longer to code and does not have great reuse. With the Simple API you write your objects and plug them together in fields and methods, every thing can be reused. Finally, although the focus of XStream is serialization, which I feel it does well it is not easily adapted for other uses such as configuration systems. Simple allows you to create template variables which can be manipulated via a serialization session.
    We use XStream in JMeter and it works great. To me, the mapping approach is more flexible than using annotations. I disagree that XStream is not good for configuration. JMeter test plans are basically configuration, and it works just fine. Using annotations to tell the application how to serialize objects out to XML is very similar to how serialization works in .NET. The biggest problem I've seen with .NET approach is that you can't do transformations easily. To do that, you'd need to use mapping. my bias 2 cents peter
  8. One can always [unless you're on a truly ancient JVM] just use the JVM's built-in XMLEncoder/XMLDecoder and/or wrap these with a little XML transformation on both ends.
  9. Or alternatively use Commons Betwixt --Calum
  10. You could use both, but what about cycles in the object graph? When serializing very large object graphs, or graphs with any degree of complication the cycles are broken on deserialization and you have a completly different object, that often won't do. This means that you must always consider the mappings, even if it intrudes in to your object model/design. Simple allows optional integration cycle stategies. Which leads to verbatim deserialization and a more efficient XML format.
  11. java.beans.XMLCoder[ Go to top ]

    Serialization support without additional libraries, and produces Serialized Objects that are JVM Version independent (a JVM 1.4 Serialized Object is readable in JVM 1.6, and vice-versa). Less human-readable, for sure, but who reads XML anyhow ;-)
  12. Re: java.beans.XMLCoder[ Go to top ]

    The XMLEncoder and XMLDecoder objects do not do serialization. For instance what happens when you have the following: public class X { private Y reference; public Y getY() { return reference; } public void setY(Y reference) { this.reference = reference; } } public class Y { private X reference; public X getX() { return reference; } public void setX(X reference) { this.reference = reference; } } How would a circular reference such as this be handled? Its performance is poor, and the XML format is awful, and not configurable.
  13. JiBX[ Go to top ]

    For simple serialization I usually use XStream, although I'll check this out next time it comes up and see how it compares. For anything more complex, nothing compares to JiBX.
  14. Re: JiBX[ Go to top ]

    I would argue that Simple can deal with much more complex situations that a binding framework like JiBX. If you have existing POJO's that you don't want to modify all you have to do is annotate them, the full object graph can then be transferred to XML and back again. I have not used JiBX but I find it hard to believe an XML schema can describe more complex relationships than Java can, or more to the point better relationships than the Java language can for a Java runtime.
  15. Re: JiBX[ Go to top ]

    I would argue that Simple can deal with much more complex situations that a binding framework like JiBX. If you have existing POJO's that you don't want to modify all you have to do is annotate them, the full object graph can then be transferred to XML and back again. I have not used JiBX but I find it hard to believe an XML schema can describe more complex relationships than Java can, or more to the point better relationships than the Java language can for a Java runtime.
    JiBX has a mapping language, which allows you to map multiple XML formats to 1 object model. Or one could read a single XML format and unmarshall it to multiple object models. Using annotations is only going to work if you have 1 model and use java. What happens if you're doing integration between different systems and platforms? I would suggest looking at JiBX. The author of JiBX Dennis participates in JAXB spec and has years of experience with XML-to-Object serialization. peter
  16. I have to say, I'm a huge fan of XStream. I recently had a case where a customer wanted to stuff an Object into a text field in a legacy DB (they could not change the schema). The solution was as simple as: str = new XStream().toXML(object); Then, when they want the object back, we do this: return new XStream().fromXML(str); Worked like a charm.
  17. I have to say, I'm a huge fan of XStream. I recently had a case where a customer wanted to stuff an Object into a text field in a legacy DB (they could not change the schema). The solution was as simple as:
    str = new XStream().toXML(object);
    Then, when they want the object back, we do this:
    return new XStream().fromXML(str);
    Worked like a charm.
    For easy cases I'm not sure one technology has that much value over another. It is when you get into tougher scenarios that you really have to do your research on which framework is best. A tough scenario to me would be versioning. In the scenario above, what happens when your objects change a bit from release to release and you still have the requirement to load old data? How does Simple, XStream, XMLBeans, JAXB, etc handle that case?
  18. You can perform loose mappings and optional elements in Simple like so: @Root(strict=false) public class MyObject { @Attribute(name="version") private int version; @Element(name="element", required=false) private String element; @Validate public void validate() { // validate here } @Commit public void commit() { // commit or translate here } } So excessive elements and attributes can be ignored and if some elements or attributes were not in the previous version they can be configured as optional. When the deserialization is complete the details can be validated and committed via persister callbacks.
  19. Can simple do transformations like what JiBX does on this page? http://jibx.sourceforge.net/tutorial/binding-structures.html Just curious. peter
  20. You can perform the same types of bindings described on this page, however the XML mappings used by Simple require more structure and so code intervention would be required for the flattened binding and split binding described. For example, flattened binding using the provided XML source could be done as follows. @Root(name="customer") public class Customer { private int customerNumber; private String firstName; private String lastName; @Element(name="person") public void setPerson(Person person) { this.customerName = person.customerNumber; this.firstName = firstName; this.lastName = lastName; } private static class Person { @Element(name="cust-num") private int customerNumber; @Element(name="first-name") private String firstName; @Element(name="last-name") private String lastName; } } Customer customer = new Persister().read(Customer.class, source);
  21. Interesting, so as long as there's only mapping from object to XML, it's ok. What happens when there's 5 XML formats that need to serialize to a single object model? I don't think annotations is going to be a good option for those kinds of cases. With XStream, I can implement multiple mapping classes to transform multiple XML formats to a single object model. With JiBX, I would only need to define the mapping. peter
  22. One task I've seen some XML mapping utils fail is when handling lists in scenarios such as the following one: public class Person { private String lastName; private String firstName; } public class PersonList extends ArrayList { } public class PersonGroup {´ private String groupName; private PersonList personList; } I'd want the XML to be like this: group1 Can Simple 1.2 can do this ? I know http://jakarta.apache.org/commons/betwixt/ can, but I've failed on that with jaxb and others.
  23. Yep the following will do it: @Root(name="person") public class Person { @Attribute(name="lastName") private String last; @Attribute(name="firstName") private String first; } @Root(name="personGroup") public class PersonGroup { @Element(name="name") private String groupName; @ElementList(name="personList") private PersonList list; } PersonGroup group = new Persister().read(PersonGroup.class, source); Done!
  24. I'm not so sure that the lack of code-configurable mapping is a strength. One problem I've always had with things that rely on annotations is that you've essentially coupled your classes to a separate framework. You can't build with the annotations unless you've got the library. That to me is a major weakness; I don't want to have my business model tied to the specifics of a serialization mechanism. There's also the scenario of trying to serialize objects that you're using from a separate library. And, of course, the problem of using several frameworks that all want to use annotations. How messy do things get when you try to annotate persistence, XML serialization, and searching (Lucene/Compass) all on one class? I don't have a problem with annotations on things like Tapestry pages, where the classes you are annotating are already dependent on a framework. But underlying business objects, that may be used in more than one scenario by various parts of your application, shouldn't be sullied by annotations related to an entirely separate concern (in the AOP sense of the word). .NET serialization is interesting in this regard in that it's default use relies on annotations but everything can also be done programmatically. XStream is somewhat similar to this but in my experience can be difficult to work with (e.g., try using xstream on classes returned and "decorated" by hibernate and you'll get all sorts of unwanted noise that isn't as simple as it should be to turn off).
  25. One problem I've always had with things that rely on annotations is that you've essentially coupled your classes to a separate framework.
    That's why I'm not liking Guice. BTW in using Simple to export a hierarchy of objects I've created a couple of adapters. Therefore, yes, I'm coupling my app to a framework but, no, I'm not coupling the model. It's a sort of an exporting subsystem.
  26. I'm not so sure that the lack of code-configurable mapping is a strength. One problem I've always had with things that rely on annotations is that you've essentially coupled your classes to a separate framework.
    True, but when you use code configurable mappings you are performing another form of coupling. Without the implemented mappings you can no longer perform the persistence process, you must now maintain the mapping code, not necessarily a bad thing but it does require much more intervention and is not very dynamic. For example take the following: @Root(name="name") public class Example { @Element(name="unknown") private Anything object; public void setAnything(Anything object) { this.object = object; } } @Root(name="anything") public abstract class Anything { } public class Something extends Anything { @ElementList(name="foo", type=Anything.class) private Collection list; } public class SomethingElse extends Anything { @Element(name="blah") private String blah; } When you have truly dynamic serialization you dont need to know anything about the code or XML. You can simply plug one object into to the another and you can convert to an from XML. For instance; example.setAnything(object); You dont need to know about the objects you are using, their types, or anything about the fields or methods. It will be dynamically transferred to XML based on annotations.
  27. XStream and Hibernate[ Go to top ]

    try using xstream on classes returned and "decorated" by hibernate and you'll get all sorts of unwanted noise that isn't as simple as it should be to turn off).
    public HibernateXStream() extends XStream { omitField(AbstractPersistentCollection.class, "owner"); omitField(AbstractPersistentCollection.class, "cachedSize"); omitField(AbstractPersistentCollection.class, "role"); omitField(AbstractPersistentCollection.class, "key"); omitField(AbstractPersistentCollection.class, "dirty"); omitField(AbstractPersistentCollection.class, "storedSnapshot"); omitField(AbstractPersistentCollection.class, "initialized"); }
  28. I have been using XStream for the past 8 or 9 months. My original motivation for using XStream came during prototype development where we wanted to use XML as our data storage format for graph (JGraph) based data. I wanted an easy way to serialize our graphs while not having to worry about graph cycles. Xstream worked very well for this. As often happens, our prototype was a great success and for the next phase of production development we decided to continue to use xml files as our graph storage format, however for the production code we needed to be able to implement some level of backward compatibility between the xml file formats that might evolve over subsequent releases. Not wanting to change horses in mid-stream, we continued to use XStream, but used XStream's Converter interface to take direct control of how we marshall/unmarshall our objects. I developed a design pattern based on reflection and Java annotations to tag the unmarshalling routines in our converters with a version support tag. This also seems to be working out well for us. So whats my point? I guess I have 2: 1. XML to Java binding technologies seems to be elicit the kind of responses you see when discussing politics and religion. With all of the various technologies available, choosing the right one for your needs can take a fair amount of evaluation time; and in the long run you can pretty much get any of the technologies to do what you want. Would be nice if there were some sort of XML serialization benchmark or evaluation checklist that addressed some of the issues discussed in these posts. 2. Versioning and backwards compatibility. Backwards compatibility to support changes to xml file formats or changes to the Java binding objects does not seem to be addressed directly by most serialization technologies in general. When using XML purely for configuration files, it is often not a big issue. However when using XML for program state storage where you need to support a large installed user base it would be nice of their were some more standard mechanisms for maintaining backwards compatiblity. I persoonally decided to NOT go the often used route of use a series of if-then-else or switch statements in my unmarshalling code (we only need to support backwards read capability) and came up with my own scheme which i believed in cleaner encapsulation of version specific code. Would like to here about other peoples experience with versioniong and backwards compatibility.