> From: Brian Jones
> Subject: Re: Excellent News About java.io
>
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > > From: Maxim Kizub [mailto:[EMAIL PROTECTED]]
> > > Subject: Re: Excellent News About java.io
> > >
> > >
> > > >As I think we told Stuart, those items you're talking about
> (overriding a
> > > >method when the spec doesn't override) are entirely OK to do. Spec
> > > >compatibility means conforming to the APIs, period.
> > >
> > >
> > > Hello.
> > >
> > > I don't know about classes and methods you mean. Sometimes this
> > > is ok. But be carefull about "super.foo()" constructions.
> > >
> >
> > We control all the classes from Object on down, so super.foo()
> should not be
> > a problem. We'll know if we insert or remove a class in the inheritance
> > tree, which is what I presume you're talking about.
> >
> > As long as *any* method is syntactically identical (same
> modifiers, name,
> > arguments) and functionally identical to the spec, it is
> conformant to the
> > public Java API. If no difference can possibly be detected,
> then for the
> > purposes of those doing the detecting, there is no difference.
>
> The only way to detect this as _not_ different is to identify the
> inherited functions and ignore them where we overload and Sun doesn't.
> Should I look into this?
>
For the purpose of API conformance, yes. I think that Reflection-based tool
will be the best way to do this since it can just get a full list of methods
for the class more easily than a decompilation tool.
This script is still useful, though. It's probably a good idea to remind
ourselves of the places where we override and Sun does not, and vice versa.
*Especially* vice versa. If you don't override something and Sun does, it's
likely there's something functional you're not taking into account. Same
with them; if we have to override and Sun does not, they likely have a bug
or design flaw.
The only way it's possible to detect this sort of thing is if someone does a
Class.get[Declared]Method().getDeclaringClass(). That will return something
different depending whether the class library is Sun or us. I think it's an
arduous restriction just to account for that one case.
I believe that we need to follow Java's binary compatibility rules and
nothing more. I remember reading somewhere an article or something on that
by Sun that stated what differences would break binary compatibility and
what differences would not. Overriding/not overriding a method did not
break binary compatibility. Changing the functionality, return value, or
thrown exceptions of a public/protected method or constructor, or removing
the method altogether from the class (including superclasses) breaks binary
compatibility. Removing fields breaks compatibility. Removing classes
breaks compatibility. No other changes that I can remember will break
compatibility.
--John Keiser
