On Sat, May 06, 2006 at 12:33:52PM +0700, Vladimir Ivanov wrote:
> Recently I thought about guaranteeing binary and source compatibility
> between HARMONY API and other compatible J2SE API implementations, what is
> our goal and how to check it, automation. Let me share my thoughts - for us
> to understand clearly what we want and how to test it.
Thanks, vladimir, very clear!
=== Some observations ===
>
> Observation #1: I think, in general, binary compatibility is a weaker
> requirement then source compatibility and is completely covered by source
> compatibility.
Hmm. For the "general" form of "general", this is not true, which stems from
the use of preprocessors and non-deterministic transformations with which the
non-java world is full. Eg when you do C development and change the definition
of how big an int is, you lose binary compatibility but preserve source
compatibility if this definition is inherited.
In the specific, you might very well be very right here, which is quite
interesting...how'd you come to these observations? Can I read more about them
elsewhere?
> Observation #2: I think, talking about 1.4, checking of 2-way binary
> compatibility + throws clause + inheritance hierarchy will guarantee 2-way
> source compatibility. I did not find any contra examples.
+ serialized form
I can imagine naughty/hacky code that uses reflection would be able to violate
that rule too. The AOP toolkits are a good example of pushing the limits, eg
aspectwerkz @ codehaus.org.
> Observation #3: In 1.5, however, checking of 2-way binary compatibility+
> throws clause + inheritance hierarchy does not guarantee 2-way source
> compatibility. Why? - generics, enums, annotations.
Yup.
=== What is our (Harmony) goal? ===
>
> In terms of these definitions, ideally, I suppose we want that Harmony is
> 2-way source compatible with the conformant J2SE API implementation (RI API)
> to make sure that any application compiled with RI API can be compiled with
> Harmony and vice versa
yep, 2-way-source compatible and 2-way-binary compatible.
=== Automation: what does JAPI check? (http://www.kaffe.org/~stuart/japi/) ===
You should put some of the info you wrote down in this e-mail up there,
its quite valuable :-)
=== Questions ===
> 1. Can we think of other cases when JAPI does not guarantee 2-way source
> compatibility, talking about 1.5 language?
No, I think you got the main ones in terms of the 1.4->1.5 change.
> 2. What more checks should be added to JAPI to guarantee 2-way source
> compatibility for 1.5?
You know, I can't even think of a good way to do implement the checks for
the generics, let alone think of more!
> 3. Does somebody know other tools that can check 2-way source
> compatibility for 1.5 to compare with JAPI?
Not me! From seeing what's happening with gump and its transition to use
1.5 for building the ASF stuff, I will assert that sun doesn't know of
something like that either, eg,
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-jdk15.html
is rather obvious in that respect, but in fairness most of the mess is all
handled within xerces/xml-apis (which is the well known "java xml hell"
problem) so we haven't seen all that many "ripples of brokenness"...
cheers!
Leo
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
