dev@jaxb.java.net

Re: [jaxb-sources] CVS update [issue-62_64]: /jaxb-sources/jaxb-ri/xjc/src/com/sun/tools/xjc/reader/xmlschema/bindinfo/

From: Joe Fialli <Joseph.Fialli_at_Sun.COM>
Date: Mon, 20 Jun 2005 17:03:28 -0400

Kohsuke Kawaguchi wrote:

> Aleksei Valikov wrote:
>
>> Hi.
>>
>>> The changes for issue 64 looks good to me (besides the following one
>>> small bug),
>>
>>
>> Would you mind correcting it?
>
>
> Will do. I just wanted to make sure that you'd agree with the change.
>
>>
>> > but because the branch contains fixes for both 64 and 62,
>>
>>> and because I have a compatibility concern about issue 62, I cannot
>>> merge this branch into the trunk right away.
>>
>>
>> > My only concern is the compatibility. I believe we cannot generate
>> > public methods that are not in the spec.
>>
>> Maybe I'm wrong, but the spec just says typesafe enums should be
>> implemented as [BLOCH]. Which is quite vague. I think typesafe enum
>> interface is not define in the spec. Am I wrong here?
>
See Section 5.2.3 Type Safe Enumeration for methods that are specified
to be generated.
(Specifically, 5.2.3.5 for methods and constructors and 5.2.3.3
Constant Fields)

>
> I thought there's a part that actually talks about the generated
> method one by one with its signature. And I think TCK is probably
> testing those.
>
> I'll wait for the spec guys to chime in.

JAXB 1.0 TCK checks for required methods and should allow additional
methods in its signature test.
So you can not change the return type or parameters of existing methods,
but it is okay to
add new methods. (Rationale was that JAXB 1.0 did not support all of XML
Schema and we did not
want to prohibit support by specifiying both a lower and upper bound on
signatures. Thus, only
specified a lower bound on generated API not an upper bound.)
This is not stated explicitly in JAXB 1.0 Compatibility section of
specification.
It should be stated in the JAXB 1.0 TCK User Guide. (need to leave
right now,
will verify tomorrow the precise statement in JAXB 1.0 TCK User Guide. )

-Joe

>
>>> Would it be possible to do issue 62 as a plugin?
>>
>>
>> Well, yes, but it would be a bit ugly.
>>
>> Let me know about you decision.
>
>
> For now maybe I should just merge your fix for issue 64 manually. Is
> that OK?
>