Re: Japitools 1.5 support tough design issue

[Andrew John Hughes]

On Thu, 2005-09-08 at 13:35 -0400, Stuart Ballard wrote:
> I think I found a solution, or at least the general shape of one.
> Sending to the list in case anyone's interested...
> 
> Two key observations:
> - If there's no possible way that 1.4 could get into an equivalent
> situation, then there's no reason we need to support a meaningful
> 1.4-style comparison of that situation.
> - Whether to use 1.4 or 1.5 rules for comparison depends on whether
> the API we're comparing *against* is 1.4 or 1.5 style - that is, the
> *first* file passed to japicompat.
> 
> There's no flag in a japi file to say "this is a 1.5 style API" and
> I'm not inclined to add one, but if we ensure that every 1.5 feature
> is noticeable in the japi file then we can always tell, on an
> member-by-member basis, which set of rules to apply.
> 
> Consider this hypothetical generic API which I'll call v15:
> class Super<T> { void foo(T t){} }
> class Sub extends Super<String> { }
> 
> Now suppose there are two 1.4-level implementations of Sub, v14a:
> class Sub { void foo(String s){} }
> and v14b:
> class Sub { void foo(Object o){} }
> 
> What should japicompat say about Sub.foo?
> Recall that japicompat A B asks the question "how well does B cover
> the API of A?"
> 
> japicompat v15 v14a should use 1.5 rules. v15's Sub has a foo(String)
> method, as does v14a, so there is no problem with foo.
> japicompat v15 v14b should still use 1.5 rules, but v14b does not have
> a foo(String) method, so it should report an error "Sub.foo(String)
> missing in v14b".
> japicompat v14a v15 should use 1.4 rules. v14a has a foo(String)
> method, but by 1.4 rules v15 has a foo(Object) method, so it should
> report an error "Sub.foo(String) missing in v15".
> japicompat v14b v15 should use 1.4 rules, but v14b *does* have a
> foo(Object) method, so no error should be reported.
> 
> Making this happen requires a few tricks in Japize and japicompat. I
> need to save the members with enough information to support both sets
> of rules, and because of the strict ordering requirement in japi files
> these members may sometimes need to be present *twice* (once sorted by
> the 1.4 meaning and once by the 1.5 meaning). Japicompat needs to
> figure out which one to ignore based on what set of rules it's using
> for that member. I also need to make sure that if Sub in v15 overrode
> the foo(String) method, Japize would still notice that it's special
> (the choice to override with a "real" foo(String) method should make
> no difference whatsoever to the japi file)
> 
> This isn't a straightforward implementation task, but at least I have
> a clue *what* to implement now.
> 
> Stuart.

Forgive me if this is stating the obvious, but for anyone who doesn't
know, the third edition of the Java Language Spec. is now on-line
and includes some information on binary compatibility as regards the 1.5
additions:

http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html

In terms of implementing Classpath, however, I think JAPI may need to go
beyond this, although I'm not altogether sure whether this is within its
scope of interest.  The 1.5 changes mainly affect compiling against the
Classpath libraries, rather than running against the binaries, and what
we really need to pick up are source-level compatability issues such as
the change of a parameter or return-type (I've already seen some in the
reflection stuff e.g. Class becoming Class<?>).  This information is
stored in the binaries, but in metadata attributes rather than as part
of the main code (which uses the erasures).  So, ideally you'd want
additional checks against this generic variant as Stuart mentions above,
in cases where the first JAPI file contains the additional metadata to
support this.
-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

No software patents in Europe -- http://nosoftwarepatents.com

"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman

Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }

signature.asc
Description: This is a digitally signed message part