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
>