Both of the alternatives you describe require the use of casts, which can fail at runtime. An advantage of code generators such as Castor is that they allow for more compile-time checking, reducing the likelihood of runtime failures. (Compare to Java generics, which require you to provide a wildcard type whenever unsafe casts are used.) You give up that advantage in your proposal.
Also, requiring the user to manage the XMLContext (whatever that is) seems burdensome. I would not completely remove those methods. Instead, maybe there is a way to make them more robust to avoid the complications you describe? - Godmar On 10/30/07, Ralf Joachim <[EMAIL PROTECTED]> wrote: > Hi Godmar, > > the driver behind deprecating/removing the static methods is, that we > frequently get requests from users that set mapping or other properties > on a (un)marshaller instance but use one of the static (un)marshal > methods. What happens is that their mapping or properties get not > recognized and the result does not look as expected (e.g. they get > exceptions at unmarshalling). The only way we see to prevent such > problems is to deprecate/remove those static convinience methods. > > On the other side you are right that these methods make your own code > shorter and easier to understand. Instead of: > > SomeXMLClass obj = SomeXMLClass.unmarshal(reader); > > or > > SomeXMLClass obj = (SomeXMLClass) > Unmarshaller.unmarshal(SomeXMLClass.class, reader); > > you will need: > > Unmarshaller unmarshaller = new Unmarshaller(SomeXMLClass.class); > SomeXMLClass obj = (SomeXMLClass) unmarshaller.unmarshal(reader); > > or better using XMLContext: > > // create context once, load class descriptors and set properties > XMLContext context = new XMLContext(); > context.addClass(SomeXMLClass.class); > > // create unmarshaller to unmarshal from reader > Unmarshaller unmarshaller = context.createUnmarshaller(); > unmarshaller.setClass(SomeXMLClass.class); > SomeXMLClass obj = (SomeXMLClass) unmarshaller.unmarshal(reader); > > Using XMLContext you will also gain some performance improvements with > the reuse of context and it makes it easier for you to use multiple > (un)marshaller instances with different configurations in one > application. This is what happens internally if you call the static > Unmarshaller.unmarshal(Class, Reader) method. > > > Having said that we do not intend to remove the static methods with next > release. Instead we will declare them deprecated for some releases > before they get removed finally. > > Regards > Ralf > > > Godmar Back schrieb: > > The static methods on Marshaller/Unmarshaller is what we're currently > > using. [ I didn't know that the generated code contained marshal > > methods, but now that you mentioned them I discovered them.] > > > > I find those methods necessary, and I don't understand the motivation > > for getting rid of them. > > Suppose I now code: > > > > SomeXMLClass obj = SomeXMLClass.unmarshal(reader); > > > > (which I like best, but see above.) > > or > > > > SomeXMLClass obj = > > (SomeXMLClass)Unmarshaller.unmarshal(SomeXMLClass.class, reader): > > > > What would the equivalent code look like under your proposal? > > > > - Godmar > > > > > > On 10/29/07, Werner Guttmann <[EMAIL PROTECTED]> wrote: > >> True, actually. Good point ... > >> > >> Werner > >> > >> Ralf Joachim wrote: > >>> Werner, > >>> > >>> but if we keep that switch we won't be able to deprecate/remove the > >>> static methods on marshaller/unmarshaller which cause more problems then > >>> those on generated code. > >>> > >>> IMHO removing the static methods on generated code could only be a step > >>> to also remove those of (un)marshaller. > >>> > >>> Ralf > >>> > >>> > >>> Werner Guttmann schrieb: > >>>> Claudio, > >>>> > >>>> Can I (safely) assume that you know that you can turn off generation > >>>> of these methods already now ? In other words, we might change the > >>>> default value of the property in question so that these methods won't > >>>> be generated in the future anymore. If you still want them, yo can get > >>>> them by asking for them specifically. > >>>> > >>>> Werner > >>>> > >>>> Claudio Di Vita wrote: > >>>> > >>>>> Werner Guttmann ha scritto: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> we (committers) are currently thinking about deprecating (and > >>>>>> eventually) removing all the static (un-)marshal() methods on > >>>>>> classes as > >>>>>> generated using the Castor XML code generator. > >>>>>> > >>>>>> The reason for this is simple: we'd like people to use explicit > >>>>>> (Un-)Marshaller instances as there's been a lot of confusion around > >>>>>> usage of mapping files and static methods. > >>>>>> > >>>>>> As it is very hard to get one's head around the impact of this change, > >>>>>> I'd like to hear from you, the users, what you think about this change. > >>>>>> > >>>>>> As always, if there's no feedback, we consider this suggested change as > >>>>>> acceptable and will continue going about an implementation. > >>>>> > >>>>> You are right, those static methods generates a lot of confusion. > >>>>> > >>>>> Moreover I hope that who use the classes generated with the Castor XML > >>>>> code generator instantiates explicitly a (Un) Marshaller. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Claudio > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe from this list please visit: > >>>>> > >>>>> http://xircles.codehaus.org/manage_email > >>>>> > >>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe from this list please visit: > >>>> > >>>> http://xircles.codehaus.org/manage_email > >>> --------------------------------------------------------------------- > >>> To unsubscribe from this list please visit: > >>> > >>> http://xircles.codehaus.org/manage_email > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe from this list please visit: > >> > >> http://xircles.codehaus.org/manage_email > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > -- > > Syscon Ingenieurbüro für Meß- und Datentechnik GmbH > Ralf Joachim > Raiffeisenstraße 11 > 72127 Kusterdingen > Germany > > Tel. +49 7071 3690 52 > Mobil: +49 173 9630135 > Fax +49 7071 3690 98 > > Internet: www.syscon.eu > E-Mail: [EMAIL PROTECTED] > > Sitz der Gesellschaft: D-72127 Kusterdingen > Registereintrag: Amtsgericht Stuttgart, HRB 382295 > Geschäftsleitung: Jens Joachim, Ralf Joachim > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
