On Friday 19 November 2004 03:15, jon gold wrote:
> Jacob Lauemøller wrote:
> > Another great customization would be to have xjc generate constructors
> > that took all required values (in addition to the empty default ctor). In
> > this way it would be slightly easier to build JAXB stuctures
> > programmatically. Right now I have to instantiate the right *Impl class
> > and then invoke setters as needed. Perhaps emitting a seperate factory
> > class instead of a ctor would be a better idea?
> >
> > Apart from this, JAXB works really well for us -- it's fast and much,
> > much easier to use than e.g. the Axis generated classes. Keep up the good
> > work!
> >
> > Kind regards,
> > Jacob
>
> maybe i'm misunderstanding something. is there some reason you can't use
> the factory methods from the JAXBContext, or it's slightly friendlier
> child the ObjectFactory, in whatever package you've generated classes in
> to construct things?
>
> jon
Well, the way I see it ObjectFactory suffers from the same problems that the
current default ctors do (which isn't a surprise as all these factory classes
do is to invoke new on just that ctor): it provides no way to populate the
fields of the object instances it creates in order to ensure that they become
valid instances right away. You have to first create an empty instance, then
remember to call the right setters before the new instance is valid, business
logic wise.
To me, this is unfortunate as it increases the likelihood that someone will
use an instance that isn't valid (because they forgot to call some setter).
To further complicate matters, the only place where I--as a developer--can
learn about which setters to call before I have populated a new instance in
the right way is in the schema. As I see it, this further increases the
likelihood that I'll get it wrong.
Also, consider what happens when the schema evolves slightly, e.g. when a
minOccurs="0" constraint is changed into e.g. minOccurs="1". In this case the
code generated by JAXB from the new schema version will be indistinguishable
(instantiation-wise) from the code generated from the old version. In
particular, the Java compiler isn't going to alert me that I now have to
remember to provide a value for the changed property whenever I instantiate
the JAXB generated object. This increases the likelihood of subtle errors.
Sure, you can (and probably should) control changes like these by placing the
new schema in a different namespace but this isn't practical during initial
development where the schema evolves from the first early draft at the start
of the project to the final version at deployment.
If the ObjectFactory class or the ctors of the *Impl classes required values
for all non-optional values then these changes would not go undetected.
Another inconvenience introduced by the ObjectFactory classes is that all of
the create* methods throw JAXBExceptions. These are checked exceptions and as
such have to be caught and dealt with. In the current implementation of
ObjectFactory they are never actually thrown since all that class does during
a create* method is to invoke the default ctor of the corresponding *Impl
class--and that ctor cannot throw a JAXB exception.
I realize that this is really an instance of the checked-vs-unchecked
exception debate but it would seem to me that the failure to instantiate a
compiler generated implementation should be considered a system-level
exception and thus not cause a checked exception to be thrown. I mean; what
are you realistically going to do to recover from the exception anyway? What
can your code do to automatically understand and change whatever caused the
problems deep inside the bowels of jaxb?
I would prefer if the factory methods threw unchecked exceptions as this would
greatly ease their use.
Kind regards,
Jacob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net