I am trying to find a good serialization library in java world. What I need:
1. It can serialize/deserialize object into xml, of course.
2. It has to use xml definition and code can be generated by any clients. I don't want to share code with my clients. I would rather share xml definition and let them generate code from it.
I found JAXB can do No1, but I am not sure if it can adopt No2. Is there anything else I can use.
Thanks a lot.
You can use JAXB for both the requirement, it can serialize/deserialize ( or we can say Unmarshal and Marshal). The JAXB classes generated from an XML Schema are POJOs with the standard JAXB annotations. As part of Metro there is a project for JAXB providing reference implementation. JSR 222 is developed by JCP for JAXB. You can have a look at these for more details.
It has to use xml definition and code can be generated by any clients.
You can generate an XML schema from a JAXB model. This XML schema can be considered the XML definition:
How to generate xsd file using java code?
And a JAXB model can be generated from an XML schema.
http://blog.bdoughan.com/2010/09/processing-atom-feeds-with-jaxb.html
Not sure that I understand your second requirement, but xstream might be the answer
http://x-stream.github.io/
Related
I am looking for a easy to implement xml to java binding. The problem I am facing that there is more than one xml file, and I need to create one object tree from these files.
JAXB is not helping for two reason : the xmls are not usually have any schema, and second JAXB does not offer any solution for combining them.
I tried smooks too, but it also doesn't offer any multiple XML digestion system.
Does anybody have any idea?
You can do this in JAXB using an initialized XmlAdapter. Below is a link to answer I gave to a similar question:
Using JAXB to cross reference XmlIDs from two XML files
Note:
JAXB implementations (Metro, EclipseLink MOXy, Apache JaxMe) do not require an XML schema:
http://wiki.eclipse.org/EclipseLink/Examples/MOXy/GettingStarted
If you use JAXB, I suggest creating your own XSDs for the XML files your need to use. That'll help you document what you thought the schema was at the time, and help identify any future issues due to change at the source.
Then, create a class or classes that deserialize the individual documents into the JAXB-generated classes and then build the object you want from those objects.
Even if you don't use JAXB, I'd still recommend using this kind of pattern to isolate the transformation from XML to Java and keep the part of your app that knows about XML in one place, away from your business logic.
I've used XMLBeans before. Really easy and flexible to use, should be able to help you a great deal.
I have an xml file format and using that xml I want to create skeleton classes needed to serialize and de-serialize that xml. I am using Java and XStream for this.
There is tool in .net world which creates classes using xml. Is there anything similar in Java world?
I have not used XStream myself, so this solution may not 100% work for you. However, the simplest approach in Java is to use Java's Architectural Binding for XML (JAXB) API and tools. JAXB was included as part of the JDK with the release of Java 6. To generate Java code from an XML schema you would use the xjc command that comes with the JDK. Here is an example:
> xjc schemas\my-schema.xsd -d src\java -p com.company.model
This code generation method will create Java Objects that include JAXB-specific annotations that are used by the Marshaller to map the Java object to its XML format and vice versa. It will also contain number of warnings stating that the code was auto-generated and should not be modified. As long as you are not trying to automatically keep the code in synch with your XML you could ignore these messages.
Now, as I mentioned, this technique does generate JAXB annotated classes, however, the generated code may still be compatible with XStream as I believe XStream uses simple attribute name -> xml node name conversion logic.
Have a requirement so want to check its feasibility.We are using JAXB 2.x for unmarshling XML in to out existing POJO classes.below is the process we are following..
Based on the XSD provided we have already created required classes using JAXB utility.
On Run time we are passing only XML file and we first validating the XML with the preexisting XSD and if success than will move ahead with the Unmarshling.
For XML creation same process but in reverse order.
Now there is one requirement so the client want that they can pass XML and XSD to the method being developed and this method should hand over the common object as return by parsing that XML and later on they will handle the process of mapping that generic Object with the specific classes.
My question is,Is it possible in Jaxb 2.x that based on the XSD supplied it will first create required classes on the fly and than will parse XML and hand over the result to the client module so they can do the mapping work or is there any way to achieve that functionality??
Thanks in advance
In EclipseLink MOXy (I'm the tech lead) we have a feature called Dynamic JAXB, that lets you bootstrap from an XML schema and use generic objects. You might find this approach useful:
http://wiki.eclipse.org/EclipseLink/Examples/MOXy/Dynamic
Dynamic java bean from xsd
I know it Is doable. One student in my lab did almost the same thing on a different subject. Though, you will have to play with classloader to be able to load dynamically the classes you've jest created. Once that is done, you can parse the XML using the classloader that includes the new classes.
Of course, it is not as easy as it sounds like...
Have a look at the sample samples/inline-customize
located at http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/docs/2.0/jaxb/samples.html
I'm writing an import function of XML files to my Java application. I am using XOM to parse the XML files. The code for parsing the XML is not easy to understand, it is some hardcoded .getChild(3) and so on. It is hard to follow the code compared to the declarative XML document.
Isn't there a more maintainable way to parse XML documents to Java objects? I would like to have it in a more declarative way, where I can specify what tags corresponds to what Java classes.
Have a look at JAX/B - fairly simple annotation-based approach. It's a standard Java API.
There are tools to generate Annotated Java classes from XSDs or sample XML files. I describe my use of it in my blog
I really like Simple for converting XML to Java.
Have a look at Apache Commons Digester.
Agreed JAXB (JSR-222) is the best solution. Note that JAXB is a spec meaning you have a choice of implementations:
http://bdoughan.blogspot.com/2010/07/jaxb-xml-binding-standard.html
Standard JAXB allows you to specify the mappings by means of annotations, MOXy JAXB also allows you to specify your metadata via XML:
http://wiki.eclipse.org/EclipseLink/Examples/MOXy/EclipseLink-OXM.XML
If you want a maintainable solution you need to break the one-to-one relationship between XML elements found in almost all XML binding solutions, and use XPath based mapping used in MOXy:
http://bdoughan.blogspot.com/2010/07/xpath-based-mapping.html
parse google geocode with xstream
The Simple XML framework uses annotations on field and method declarations as well as on class definitions to map XML to Java and back. Its many times more lightweight than JAXB (which pulls in tonnes of dependencies). In fact it has no external dependencies at all. And its faster too. I tried JAXB many times, but found the annotations and functionality awkward and cumbersome. Check out the Tutorial.
Check Castor XML Mapping
Here is documentation for same : http://www.castor.org/xml-mapping.html
I finally found XStream that was easy to use and parses the XML in a declarative way.
In Java for XML marshalling/unmarshalling one can use JAXB, JIBX, CASTOR, ADB etc.
But out of these which is most generic & commonly used? Or is there any other utility available?
The standard is the JAXB (JSR 222), and the famous project with this name is the reference implementation. Unlike JAXB 1.0, JAXB 2.0 RI is quite good, and I've used it a lot. Other libraries implements the JAXB standard (I think tha Castor and JiBX, but I have no experience with them).
I've also use XStream, which was very easy and simple - it has a proprietary API though.
I don't know of any benchmark other than https://bindmark.dev.java.net/old-index.html - notice it is a 4 year old one. perhaps you can take it's ideas or any usable code it may have and run some tests yourself.
I personally use XMLBeans. I like it more than JAXB (and I am biased in favour of things from Sun since they should be more "standard"). I cannot speak to the commonly used part of it though.
JAXB is preferred because of following reasons:
No extra jaxb libraries are required if you are using JDK1.6 or above, because JAXB is bundled in JDK 1.6.
The jaxbMarshaller.unmarshal() contains a lot of overloaded methods, find one that suit yours.
JAXB is pretty easy to understand and operate. what it requires is couple of annotations like #XmlRootElement and #XmlAccessorType along with four lines of code
Modifying XML files in Java is much easier using JAXB as compared to other XML parsers like DOM and SAX because you only deal with POJOs
JAXB is more memory efficient than DOM or SAX parser.
JAXB doesn't require XML schema to work. Though you can use XML Schema for generating corresponding Java classes and its pretty useful if you have large and complex XML Schema which will result in huge number of classes but for simple usage you can just annotate your object with relevant XML annotations provided by JAXB package i.e. java.xml.binding and you are good to go.
I use CASTOR mapping and IMHO it is very easy to use provided you are familiar with XML. All you need to do is to create Java objects and map them to the XMl using a mapping file. The mapping file is required if your XML is a complex one. If it is a simple and straight forward XML, CASTOR will itself look for respective Java class which matches the XML element name [Castor uses Java's Reflection APIs to do this].