Les Hazlewood wrote:
> 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.
>
Thanks for your feedback. I will comment inline below on the JAXB expert group
design decisions.
> 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?
A basic premise in JAXB is to extract semantically meaningful names out of an
XML schema and use them in the Java representation. When the names are
extracted, they are extracted "as is" except for one exception case that
I will cover at the end of this comment. It is important to extract them
as is by default to preserve name uniqueness and thus avoid naming collisions
in the generated Java code. For example, if one had an element foo and
an element fooList, a name collision would be caused by default binding
if all repeating occurance elements bound to a List had "List" appended
as a suffix by default binding. There have been other requests for providing a
global customization to append a suffix to all List properties and this request
has merit and will be considered for the next release. However, by default, it
is better to not perform any unneccessary manipulations on the XML Schema names
that are being mapped to Java.
The one exception case where JAXB does append a suffix, namely
composing a Java interface name from an element's name and
adding a "Type" suffix to represent an element's anonymous complex
type definition has introduced name collisions in some schemas.
For example, we have encountered schemas that had an element
with an anonymous complex type definition called "Foo" and
another element and/or complex type defintion with the name
"FooType". Luckily, using globalBindings nameXmlTransform customization
one is able to correct these collisions with one customization.
Based on experiences with these collisions, the default binding will
not be modified to add "List" or "Array" to the ends of XML
elements mapped to JAXB List or Indexed properties respectively.
However, if one knows the naming conventions used in their
schema, it should be possible to specify a portable
customization that states append this suffix value to all
List properties and/or Indexed properties.
>
> 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?
To enable the most generic implementation and to allow for future support of
binding JAXB to existing Java classes, great lengths were taken to not impose
any superclass on all schema derived interfaces.
Requiring the TreeModel interface would have benefitted those who wish to
generically traverse JAXB data structures as a tree; however, there
would be a runtime performance overhead and usability issue for those who
did not wish that a TreeModel exists. There is a potential to introduce
a customization that enables this in the future; however, it is not desirable
to require that all JAXB schema-derived interfaces must support a tree model.
I hope this explains the rationale behind the current specification design
decisions.
Thank you for your feedback,
-Joe Fialli, Sun Microsystems
>
>
> Your thoughts? Comments?
>
> Thanks for your time in reading this long email :)
>
> Les Hazlewood
--