Re: Japitools 1.5 support tough design issue

[Stuart Ballard]

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.
-- 
http://sab39.dev.netreach.com/