Hi all, I've just joined this discussion list, but I've made the effort to find my answer in the list archives, but without success.
Basically I'd like to address two concerns of JAXB v. 0.90 and the cooresponding reference implementation by Sun. The first concerns the return of java.util.List from a getter method in auto-generated source code that cooresponds to an XML Schema sequence. The second is a question of reasoning of implementing the TreeModel interface in JAXB.
Question 1:
Given the following partial XML Schema definition example:
<xsd:element name="rubberDucky">
<xsd:complexType>
<xsd:attribute name="name" type="xsd:token"/>
<xsd:attribute name="color" type="xsd:token"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="bathtubToys">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="rubberDucky" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
We can envision an instance such as:
<bathtubToys>
<rubberDucky name="Fred" color="yellow"/>
<rubberDucky name="John" color="blue"/>
<rubberDucky name="Jack" color="green"/>
</bathtubToys>
The Sun reference implementation would generate the cooresponding BathtubToys, BathtubToysType, RubberDucky, and RubberDuckyType interfaces as needed.
Continuing with this example, the BathtubToysType interface would have a "getter" method with the signature:
public java.util.List getRubberDucky().
This is where I have a large conceptual problem with such a signature. However, I'm not sure if this signature is done this way because of the reference implementation or if its a requirement from the 0.90 version of the spec. I've read most of the spec, but I can't remember, so please inform me either way.
To me, this method should be called getRubberDuckyList().
Conceptually the method signature getRubberDucky() implies there is only one, just like mutator methods for strings. I've noticed this is a conceptual problem for many other programmers, as in my google searching, I've seen the following question asked numerous times:
"How come there is a getRubberDucky() method that returns a List, but no setRubberDucky(List myList) method that allows me to set one? I.E. how do I add a RubberDucky to the list of BathtubToys?"
The common answer is "just do getRubberDucky().add(myRubberDucky)", which of course is a good answer given the implementation. However, *conceptually* this method signature does not make sense given the singualar naming convention for something that really can contain multiple entries.
It would not be difficult at all to change the method signature...and would in fact help clear up future confusion.
Some may think that I'm being picky over small details. However a key factor that makes the OO paradigm so powerful (especially Java) is the detail of addressing human intuition. In my opinion this small change could resolve many questions that are sure to arise in the future as JAXB becomes more widely used.
How difficult would it be to implement such a change? Is there way to submit a feature request to the JAXB standards body?
Question 2:
Why don't JAXB classes implement the java.util.TreeModel interface and supporting constructs (i'm not referring to JTreee, which has no context in this discussion of XML)? There are many applications that I think of that could benefit from such an architectural add-on. Most notably, I think of wide scope things such as n-ary searches and pre/in/post order searches.
I don't see this change as altering how people currently use JAXB. I only see it as enabling more functionality to the programmer who might need such features.
Could this also be submitted as a formal feature request?
Your thoughts? Comments?
Thanks for your time in reading this long email :)
Les Hazlewood