There are plenty of software projects that read XML configurations from files or network streams to provide configuration and initialization of the system. There are many ways of doing this common configuration stuff. The XML 2 Java Binding (X2JB) tool was designed with simplicity in mind to make these common configuration tasks very simple. The tool was developed with an intent of extensibility so it can be extended to unpredictable boundaries and easily used in many software projects. X2JB Java tool consists of three basic components:

• X2JB Core - provides the full implementation of binding mechanism that is independent from used binding provider
• X2JB Default Handlers - binding handlers for frequently used Java objects and primitives
• X2JB Providers - provider implementations that come with this project

The last two components are part of X2JB's extensibility mechanisms - user can use delivered ones or he can write his own.

...can it unmarshal back into XML?... The round-trip is what I see as the important factor in the binding frameworks. I wrote a naive JAXB myself so I can get the beans to talk JSON as well as they talk XML. But as mentioned, the round-trip is the important part. Once you've done processing things, there are many times in a serving solution where it's terribly handy to get the data stream back out. Otherwise it will be just for configurations which has competition from Digester and so forth. If it can be round-tripping, it can play in the XML serving/processing space.

No, it's just one directional mapping only from XML to Java. It is intended to be used for configuration and notification purposes only ;-)

Isn't JAXB2 already supports all that stuff and even more? It is configurable via annotations too and its a JSR (JSR-222 to be precise)... Why should I use X2JB instead of JAXB2 then?

+1 There is a real lack of imagination these days. Some ideas for open source projects : - a real web based project management tool (like OPX2), - a tool that generate automatically unit tests for web projects, - monitoring tool (like Patrol), - and so on...

Yes, you are right. JAXB supports all that stuff and it is really cool tool. But it is so complicated to use it and to customize its binding mechanisms. The advantages of X2JB over JAXB2 are: * really simple read only API - it has only 2 classes, 4 interfaces and one optional annotation class * fully interface based - user defines only interfaces and mapping for each method of that interface * it is really very easy to customize the binding process * just one method call does all the stuff for you

Isn't JAXB2 already supports all that stuff and even more?

It is configurable via annotations too and its a JSR (JSR-222 to be precise)...

Why should I use X2JB instead of JAXB2 then?

JAXB is part of J2EE specs, and also part of JAX-WS. Given that, I wonder whether there is any compelling reason for using X2JB. Simplicity to use is a relative term, and most often developers should and will choose standard solution for a given problem.

X2JB is not intended to be the replacement for JAXB. It is just another way how to configure your application/server. Take a look to webapp demo that is part of X2JB distribution and you will see what is it good for ;-)

JAXB is part of J2EE specs, and also part of JAX-WS. Given that, I wonder whether there is any compelling reason for using X2JB. Simplicity to use is a relative term, and most often developers should and will choose standard solution for a given problem.

Comments indicate this isn't round-trip or persistence oriented. If that's the case, I'd say XStream has this beaten soundly. XStream might not be a full persistence/binding platform, but it is dual-directional to/from XML. And it is practically zero-config. Unless you are hamstrung by a) legacy configuration objects or b) legacy XML format requirements and you can't change those, then use XStream.

Comments indicate this isn't round-trip or persistence oriented.

If that's the case, I'd say XStream has this beaten soundly. XStream might not be a full persistence/binding platform, but it is dual-directional to/from XML. And it is practically zero-config.

Unless you are hamstrung by a) legacy configuration objects or b) legacy XML format requirements and you can't change those, then use XStream.

Thanks for the tip on XStream. This is exactly the kind of thing I've been looking for as part of my 'Java XML best practice™'. One thing (not terribly important) does XStream have any tools for generating a schema (not necessarily W3C) from a Java class to match the XML it creates?

Another option which allows bidirectional serialization is the Simple XML serialization framework. http://simple.sourceforge.net/ This differs from XStream in that it does not require any configuration, not configuration files, schemas, or even code mappings (which XStream seems to use a lot of). Also XML emitted from the Simple XML serialization framework is much more human readable and editable. Finally, after taking a look at X2JB it seems to me even less intuitive than even JAXB, and requires a lot of work to get few results.