It seems that simply replacing ArrayList by Vector solves the problem,
since Vector<T> implements List<T>. (It seems that it's even possible
to replace List<T> by Vector<T> as well, but that isn't necessary.)
Or would wrapping all the ArrayList<T> into Collection.synchronizedList<T>
solve
your problem?
In either case I'd suggest a simple sed or Perl script to post-process
the generated files.
-W
On Sun, Oct 4, 2009 at 11:43 PM, Roger Parkinson <roger_at_senanque.co.nz>wrote:
> Sure, I understand the limitations, or I think I do. :-)
>
> We really, really like specifying all our business objects in XSD and
> generating them. It simplifies so many things and is an excellent
> approach from a conceptual point of view at least. Simple example: we
> suddenly find we need to expose an object graph as part of a web
> service, how much coding? Almost none.
>
> But it does insist on delivering all collections as ArrayList. It seems
> a minor change to be able to specify an alternate class. I'd be happy to
> use the same class everywhere, just not ArrayList. ie defining a new one
> globally would be fine.
>
> It's not like we serialise everything back and forth all the time, but
> regardless of that we still have to use ArrayList. Actually I did make
> some progress here. I added a plugin on the generator that injects some
> code around the instantiation of the ArrayList. That handles cases where
> we don't serialise, but we do tend to use serialised classes
> interchangeably with nonserialised and that can lead to inconsistencies
> where the list class is different.
>
> Thanks for listening
> R
>
>
> Wolfgang Laun wrote:
> > Serializing Java using XML is bound to have limits, even with all the
> > customizing and plugin features. XML Schema isn't a design tool for Java
> > classes. Using objects created from the xjc generated classes in an
> > application where thread safety (or any other facet of dynamic
> behaviour)
> > matters obviously raises issues that are not addressed by the JAXB
> > specification.
> >
> > One way to go would be to avoid Java class generation from a schema and
> to
> > annotate Java classes with JAXB annotations. This way it would be easy to
> > deal with synchronisation, or use better strategies for list allocations,
> > etc.
> >
> > If you want to stick with generating classes, you might consider using a
> > design pattern akin to Decorator or Proxy to deal with synchronisation or
> > other dynamic behaviour issues.
> >
> > And you always have the option of not using some or all of the document
> > classes in your application's business logic at all. Transforming between
> > related objects does create an overhead, but it'll also effectively
> decouple
> > the XML representation from the business logic.
> >
> > .W
> >
> > On Fri, Oct 2, 2009 at 2:47 AM, Roger Parkinson <roger_at_senanque.co.nz
> >wrote:
> >
> >> I could use this too.
> >> I had a recent performance issue with ArrayList, it goes slow as the
> size
> >> gets past a certain point.
> >> Had to change it to a TreeSet (or similar, I forget the details).
> >> It wasn't anywhere near JAXB so that was easy, but it might have been,
> in
> >> which case I would looking for an answer to this question.
> >>
> >> Regards
> >>
> >>
> >> rubinod wrote:
> >>
> >> Hi,
> >>
> >> I need something thread safe so even a Vector or something from
> >> java.util.concurrent would be more useful.
> >>
> >> Thanks
> >>
> >>
> >> Wolfgang Laun-2 wrote:
> >>
> >>
> >> This depends on PlatformType - is it an xs:simpleType?
> >>
> >> What would you like to have instead of ArrayList, and why?
> >>
> >> -W
> >>
> >>
> >> On Wed, Sep 30, 2009 at 6:28 PM, rubinod <webaccounts_at_rubino.co.uk> <
> webaccounts_at_rubino.co.uk> wrote:
> >>
> >>
> >>
> >> Hi,
> >>
> >> Say I have the following:
> >>
> >> <xs:element name="Platforms">
> >> <xs:complexType>
> >> <xs:sequence>
> >> <xs:element name="platform" minOccurs="0"
> >> maxOccurs="unbounded"
> >> type="c:PlatformType"/>
> >> </xs:sequence>
> >> </xs:complexType>
> >> </xs:element>
> >>
> >> when I run the schema through JAXB to generate the class files I get:
> >>
> >> @XmlRootElement(name = "Platforms")
> >> public class Platforms
> >> implements Serializable
> >> {
> >>
> >> @XmlElement(name = "platform")
> >> protected List<Platform> platforms;
> >>
> >> public List<Platform> getPlatforms() {
> >> if (platforms == null) {
> >> platforms = new ArrayList<Platform>();
> >> }
> >> return this.platforms;
> >> }
> >>
> >> }
> >>
> >> I would like to be able to override the default List implementation as I
> >> dont want an ArrayList- is this possible?
> >>
> >> Thanks
> >>
> >> --
> >> View this message in context:
> http://www.nabble.com/Overiding-default-JAXB-mappings-tp25684570p25684570.html
> >> Sent from the java.net - jaxb users mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>