Because of increasing configuration complexity, I want to introduce XML for my library's configuration files, and replace the existing properties files.
I would like to
Publicly describe the XML structure with XSD (so the structure is documented and can be versioned)
If possible, generate Java source code from that XSD for unmarshalling (like with JAXB / XJC). An alternative simple access method is OK too (e.g. simple XPath expressions)
Have a low footprint and few or even none additional dependencies
If the footprint wasn't an issue, I'd choose JAXB right away. Are there similar libraries with a lower footprint?
EDIT: By footprint, I don't mean consumed memory but the "size" of the library in KB/number of classes. I'd expect my rather simple use-case to be coverable by a library with about 5-6 classes. I don't need the full power of JAXB.
JAXB is Low Footprint
A JAXB (JSR-222) implementation is also included as part of Java SE 6. The classes produced are just POJOs with the necessary annotations. In the question below the poster observes that the XMLBeans classes are four times bigger than the JAXB classes.
Compiling huge schema into Java
Reducing the Number of Classes
If you start with Java classes (instead of generating them from an XML schema) you can normally keep the model smaller. The use of #XmlWrapperElement can help eliminate classes.
Reducing the Number of Classes Further
You can leverage the #XmlPath annotation in EclipseLink JAXB (MOXy), note I'm the tech lead. It leverages XPath to extend the JAXB mappings:
http://bdoughan.blogspot.com/2010/09/xpath-based-mapping-geocode-example.html
For a zero-dependency solution use the DOM or the SAX parser that is part of every Java VM.
If you want Java type binding, stick with JAXB. Even if you find a smaller size library, you will loose out by using a non-standard solution that hasn't been as extensively tested or has as many developers who know how to use it.
If you are willing to consider using non XML-technologies, then you might want to look at my Config4J library (www.config4star.org). Comparing it to your wish list...
It provides an easy-to-use schema language.
The jar file is small (102KB) and it has no external dependencies.
The one capability missing from your wish list is a tool to automatically generate Java classes from a schema definition. However, the API of Config4J is simple enough that I'm not sure you would need such a code generator. Part III (The Config4JMS Case Study) of the Practical Usage Guide manual describes a technique for building a Spring-like library to create Java objects from configuration information.
Related
Scenario
We have a java application that hosts the logic for parsing the various versions of ddex specs. For every new ddex release, we currently maintain a respective mapper to map the xml to our Application classes. This is how the process looks like:
DDEX XML -> JAXB -> JAXB Auto Gen. JAVA Classes -> Mapper Code -> Application Classes
This design is not maintainable on a long run. It leads to lot of code duplication and repetitive test efforts for every ddex release which contains a lot of fields as it is from the previous version.
I will like to know how can such a system be designed better. We are open to switch to other xml parsers too, if required.
Note: I saw this answer, but wanted to know any ddex-specific ideas too. Plus the answer is more than 10yrs old, so wanted to check if there is anything else available now.
In my view, JAXB (and data mapping technologies generally) are the wrong choice when you have to deal with frequent schema change. I've seen projects come badly unstuck on this.
Rather than mapping specific schema structures to specific Java classes, you should be using a generic tree model such as DOM, JDOM2, or XOM (DOM is the oldest, most popular, and worst of the three - I would go with JDOM2).
With a generic tree model, you can design your application to be resilient to most changes in the incoming XML.
Alternatively, use an XML-oriented programming language such as XSLT or XQuery.
I'm not familiar with ddex so this answer is not specific to that environment.
I am currently working on an application that performs the task of importing or exporting some entities. The file format being used for the same is XML. JAXB is being used for XML binding.
The problem is present XSD that defines the structure of entities has no provision for versioning. How do I get started with defining versioned XSD and subsequently XML instance documents provided JAXB lies as the underlying binding framework ?
I have read that there are three possible ways of introducing versions in XSD.
1) Change the internal schema version attribute
2) Create a attribute like schemaVersion on the root element
3) Change the schema's target namespace.
Which one best suits the usecase mentioned below?
Use case: The changes made to the XSD in the next version may invalidate the existing elements. Although the schema itself may not be backward compatible but the application needs to provides support for handling all versions of schema.
XML is designed to facilitate change and flexibility in document structures. Unfortunately, JAXB isn't. The very act of compiling knowledge of document structure into your Java source code makes change to the document structure a lot more difficult.
If structural change is part of your agenda, I think you should seriously consider not using JAXB: technologies like XQuery and XSLT are much better suited to this scenario.
I am starting a new project where I have third party XSD. My Java application needs to generate, and readm XML messages that conform to this XSD. In the past I have used Apache XMLBeans for this. It looks like XMLBeans has been retired.
What is a good replacement for XMLBeans now that it has been retired? I have used XStream on other projects but I don't recall that XStream has the ability to generate Java classes from an XSD so I am thinking that it is not a good choice over XMLBeans for this use case. I have hundreds of types defined in the XSD and would really prefer not to have to create the hundreds of Java classes to represent them in Java by hand.
In other words, using the XStream example, I have a Person type (and 99 others) defined in the XSD. Using XMLBeans I can generate the Java classes to represent these objects, but using XStream I would need to create the Java classes (e.g. Person) by hand or using some other tool. What tool should I use in this case?
Have you looked at JAXB? I haven't done anything with either of these, but googling for "alternative to XMLBeans" brings up lots of references to this package. Here's an article that compares them...
http://blog.bdoughan.com/2012/01/how-does-jaxb-compare-to-xmlbeans.html
XMLBeans has been unretired:
The Apache POI project has unretired the XMLBeans codebase and is maintaining it as a sub-project. Until now the XMLBeans codebase was held in the Apache Attic where former Apache projects are kept for the public good.
The latest release as of August 2020 is:
3.1.0 (March 26, 2019)
Having said that, I am not sure I would recommend using it, based on its history of retirement. Other solutions, such as JAXB, might be prefered since it will probably be better maintained in the future.
Is anyone aware of a library that makes the process of creating XSDs in Java a little easier than using something like a DocumentBuilder? Something like a helper or utility class. I came across the org.eclipse.xsd maven jar but I'm having ClassNotFoundException issues when working with it in Eclipse and I'm not entirely sure it's meant to be used as a standalone kind of thing. This is a bit difficult to Google for as well since there are lot of search results around automatic generation/translation from Java to XSD and vice versa.
Essentially what I need to do is to programmatically create an XSD from a certain source of data -- not Java classes.
Apache XMLSchema is a lightweight Java object model that can be used to manipulate and generate XML schema representations. You can use it to read XML Schema (xsd) files into memory and analyze or modify them, or to create entirely new schemas from scratch.
The fact that with this API one can create an XSD from scratch, it sounds as a starting point to achieve the ask; as to the fitness, it depends on what that "certain source of data" is.
I am looking at a set of parsers generated for Atom, XAL, Kml etc. seemingly using an automated technique with a XML pull based parser. The clue towards the automation is presence of "package.html" in all XML-to-Java mapped classes folders. I would like to produce a similar one for the rather large Collada 1.4 spec. My first attempt with Altova ran into small problems due the "enum" keyword. I am sure I can fix it in the next run with appropriate renaming. Khronos admit to not designing the 1.4 spec to being automated parser generation friendly.
The actual parsers i.e. XAL parser, Atom parser etc. implement the XMLEventParser interface. I would like to know if anybody has encountered/used this pattern. If so which tool can be used to map the XSD to a class set simply giving access to the data components of the nodes using getters and setters.
I'm not sure I understand your question, but it appears that you want to process XML formats like Atom and represent it in objects with getters/setters. This can easily be done with JAXB.
For an example see:
http://bdoughan.blogspot.com/2010/09/processing-atom-feeds-with-jaxb.html