those all seem like good points. have you read the thread from september:
JAXB - Automatic creation of mandatory children
it might shed some light on why there aren't value-accepting default
constructors or factory methods. i think the two questions are heavily
related (if not the same).
jon
Jacob Lauemøller wrote:
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net