Dwell in hell JaxB!

Feel free to join the JaxB bashing... ;)

As pointed by David Josh is not really happy about JaxB's behaviour.

It is even worse than Josh thinks or experienced, as the specification is based on the fact that your objects are plain Java Beans (with all the quirks of this damn spec...).

I had an equivalent unpleasant surprise while giving a training on JaxWS (which specifies the use of JaxB recently) last december.

The week before this training, I had worked on a domain-driven persistence design, with immutable objects, write-only repositories and read-only fast-lanes (will soon blog about it hopefully if it's interesting enough)...
With this purist state of mind, I started creating in front of all the "students" a beautiful domain with Immutables (BTW I should have stuck with the default examples, though I wanted to demonstrate how easy it is to use JaxWS starting from scratch).
Yet be warned, an Immutable cannot be a JavaBean, as these beasts can only be created with the default no-args Constructor and their state modified by their getters/setters....

Isn't that the stupidest thing in the world????

What would be a best candidate for disconnected transfer (HTTP usually with WS) than an immutable object?

I know for a fact that an External view of the service should separate my domain from the view I give from it to the outside, yet even if good APIs exist for the copy of the states of beans, it's still a shame to be forced into java beans which are only useful for damn Swing developments (BTW I think I could wish hell to swing for being part of the JDK and being the motivation for the addition of a default implementation of database and web services inside the JDK/JRE.... what a nonsense).

So in the end I completely agree with Josh and am still looking for a better ways to use immutables in J(2)EE applications. It seems that the whole platform was build without these beasts in mind.