> I agree that it's useful, but it's jut more work. A few questions:
Hehe. Yeah, sorry about that. Just makes using existing POJOs easier.
>
> - you have @keyAttribute, which seems to imply that elements can't be
> a key. This is easier to implement, but do you have any justification
> for not allowing elements to be keys?
I thought about this and wasn't sure how it would play out. Which
elements would be keys and which would be values? XML naturally implies
lists for sub-elements. Putting them in a Map implies that each element
has something that identifies it as unique. The only other data
structure I could think of would be a Set, but I'm not sure how to use
elements as keys.
This does bring up another good point, should the generated JAXB POJOs
implement hashcode and equals according to the XML schema? This would be
very nice to have for clients so that they can determine if two objects
are equal and use them as keys into Maps elsewhere in an application.
>
> - do you really need "retainDupliates"? If you expect duplicates,
> would you really want to use a Map?
>
Well, depends I guess on the requirements. If I'dl like all shopping
cart items by type I could have them placed into a map based on the type
attribute. In this case the value of the Map would be a List of items. I
think it could still be useful.
>
> One possible easier (for us) approach would be to design the basics so
> that you can add this kind of functionality by deriving/modifying a
> generated class.
Yeah, that would work also. That brings us back to our discussion about
handling modifications to generated classes. If the annotations are
written to support this, I could just write my own POJO and use that
with the JAXB (un)marshaller. But, if I want to generate the classes and
then need to modify them to support the Map, then we need to figure out
how JAXB should handle obejct modifications and/or additions.
>
> This is RI-specific, but there's the com.sun.xml.bind.ObjectLifecycle
> interface you can implement on your object (see the attached) so that
> you can get notified when your object is unmarshalled. This will allow
> you to set up your own Map.
That would work out alright, but would be cooler if it was baked in.
This requires more coding by the developer and the code that uses JAXB
must know that it needs to setup an ObjectLifecycle that can handle the
specific Object it is working it. Plus, it might require some instanceof
and casts. Although it is more work, it would be much cooler if JAXB
handled this stuff.
Let's return to the modification dialog we started a while back in a
separate email and figure out if we can come up with a cool solution
that will allow modifications to the JAXB generated classes.