Re: Japitools 1.5 support tough design issue

[Tom Tromey]

>>>>> "Stuart" == Stuart Ballard <address@hidden> writes:

Stuart> The problem is that in the japi file we want to have information about
Stuart> reality (to support meaningful comparisons against 1.4-level APIs)
Stuart> *and* about fairyland (to support meaningful comparisons of the new
Stuart> 1.5 features). In this case they're mutually exclusive as far as I can
Stuart> tell :(

Stuart> Suppose we have this:
Stuart> class Super<T> {
Stuart>   void foo(T t);
Stuart> }
Stuart> class Sub extends Super<String> {}

Suppose we extend this a little:

    class Sub extends Super<String> { void foo(String x) ... }

In this case, a 1.5 compiler will emit both Sub.foo(Object) and
Sub.foo(String).

This has always been valid in bytecode -- there was just no way to
construct such a .class from a pre-1.5 java compiler.


My first reaction here is to say that japi should just be naive.  For
instance, in this case, it could just treat the two things as
different methods, distinguishing them by their descriptors (what was
called a 'signature' in the 1.4 days -- the signature without any
generic information).

But maybe that yields too many false positives when comparing a 1.5
classpath against a 1.4 jdk?  (Do we care about this?)


Plan B, I think, would be to try to emulate "real" 1.5 overriding
rules.  Perhaps this would only mean recognizing and discarding
methods with ACC_BRIDGE set, and then looking for subclassing
relationships in argument and return types (which is a pain as it
means constructing a type hierarchy) -- though perhaps this could be
done by parsing the body of the bridge methods.

Tom