harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ivanov" <ivavladi...@gmail.com>
Subject Re: [classlib] HARMONY vs. J2SE API source, binary compatibility: JAPI for 1.5 required
Date Sat, 06 May 2006 10:21:01 GMT
On 5/6/06, Anton Avtamonov <anton.avtamonov@gmail.com > wrote:
>
> Vladimir,
>
> - Am I right that source/binary compatibility implies that
> package-private implementation also matches?

If it does then how does it fit to clean-room?



No.



> - Do we really need to be source/binary compatible?

Do you think that existing compatibility guideline
> http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
> is not enough?



Seems, it is enough. But letter was about how to test it. We have not such
kind of tests.

But if we will use JAPI with some add-ons, for example, we can check '*Comply
with the Java Specification*' automatically.

 Thanks,
  Vladimir Ivanov


Sorry if it was discussed before and I missed it.
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
> On 5/6/06, Vladimir Ivanov <ivavladimir@gmail.com> 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.
> >
> >   Here is the summary:
> >    · For 1.4 J2SE API implementation - JAPI tool, being applied in both
> > ways (RI vs. HARMONY and HARMONY vs. RI), tests 2-way binary
> compatibility
> > between two J2SE API implementations and only one small update to check
> the
> > inheritance class hierarchy should be added to tests 2-way source
> > compatibility.
> >    · For 1.5 – JAPI tests 2-way binary compatibility. For checking 2-way
> > source compatibility JAPI lacks some 1.5 language specific checks in
> > addition to checking inheritance class hierarchy. We need some add-ons
> for
> > JAPI.
> >
> >  Details:
> >
> >  First, definitions…
> >
> > Binary compatibility – if class A can be linked with a set of classes B
> and
> > a set of classes C than sets B and C are binary compatible (from the A's
>
> > point of view). For Java it is defined in the JLS chapter 13.
> >
> > Source compatibility – if a source of class A can be compiled with a set
> of
> > classes B and a set of classes C (by conformant compiler) than sets B
> and C
> > are source compatible.
> >
> > 1-way binary/source compatibility – any arbitrary class A,
> linked/compiled
> > with a set of classes B, can be linked/compiled with a set of classes C.
>
> >
> >
> > 2-way binary/source compatibility – any arbitrary class A,
> linked/compiled
> > with a set of classes B, can be linked/compiled with a set of classes C
> AND
> > vice versa – any arbitrary class A, linked/compiled with a set of
> classes C,
> > can be linked/compiled with a set of classes B.
> >
> >
> >  Some observations
> >
> > Observation #1: I think, in general, binary compatibility is a weaker
> > requirement then source compatibility and is completely covered by
> source
> > compatibility.
> >
> > 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.
> >
> > 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.
> >
> > Example for generics:
> >
> > class A<T> {
> >    public void m(T p) {
> >    }
> > }
> >
> > class A {
> >    public void m(Object p) {
> >    }
> > }
> >
> > class MyClass {
> >    public static void main() {
> >        new A<String>().m("abc");
> >    }
> > }
> >
> > Both "A"s are 2-way binary compatible, but, MyClass can not be compiled
> with
> > non-parameterized A.
> >
> >
> >  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 (as well as linked, that is guaranteed by the
> > "Observation #1").
> >
> >
> >  * Automation: what does JAPI check? (
> http://www.kaffe.org/~stuart/japi/)
> >
> > Being run in two ways (for example, RI vs Harmony and Harmony vs RI)
> JAPI
> > checks 2-way binary compatibility for both 1.4 and 1.5 language-written
> > APIs.
> >
> > It compares method, class signatures in two sets of API binaries and,
> being
> > run in two ways, checks the following:
> >
> > ---------------------------------------------------
> > Checks                                       | JAPI
> > ---------------------------------------------------
> > Classes: modifiers (access+abstract)         |  +
> > Classes: add/remove super classes            | +/+
> > Classes: add/remove super interfaces         | +/+
> > Classes: order of super class hierarchy      |  -
> > Fields: modifiers (access+final)             |  +
> > Fields: change value for constant            |  +
> > Fields: change static/transient              | +/-
> > Fields: add/remove                           | +/+
> > Methods: modifiers(access+abstract+final)    |  +
> > Methods: change static/throws clause         | +/+
> > Methods: add/remove                          | +/+
> > Constructors: modifiers(access)              |  +
> > Constructors: add/remove                     | +/+
> > Interfaces: modifiers                        |  +
> > Interfaces: add fields/methods               | +/+
> > Interfaces: remove fields/methods            | +/+
> > ---------------------------------------------------
> >
> > So, talking about 1.4, two runs of JAPI - Harmony vs RI and RI vs
> Harmony
> > and small JAPI update (check that it is illegal to re-order class
> > inheritance, actually, it is checked, but indirectly) will check 2-way
> > source compatibility (any deviation in the classes will be checked,
> except
> > for transient).
> >
> > What about 1.5? – so far, seems like to check 2-way source compatibility
> > JAPI lacks:
> >
> > Checks  | JAPI
> > ----------------------
> > generic         |  -
> > annotation      |  -
> > enum            |  -
> >
> > What else?
> >
> >
> >  Conclusion:
> >
> >    · For 1.4 J2SE API implementation - JAPI tool, being applied in both
> > ways (RI vs. HY and HY vs. RI), tests 2-way binary compatibility between
> 2
> > J2SE API implementations and only one small update to check inheritance
> > class hierarchy should be added to test 2-way source compatibility.
> >
> >    · For 1.5 – JAPI tests 2-way binary compatibility. For checking 2-way
>
> > source compatibility JAPI lacks some 1.5 language specific checks. We
> need
> > some add-ons for JAPI.
> >
> >
> >  Questions:
> >
> >  1. Can we think of other cases when JAPI does not guarantee 2-way
> source
> > compatibility, talking about 1.5 language?
> >
> >  2. What more checks should be added to JAPI to guarantee 2-way source
> > compatibility for 1.5?
> >
> >  3. Does somebody know other tools that can check 2-way source
> > compatibility for 1.5 to compare with JAPI?
> >  Thanks,
> >  Vladimir Ivanov
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message