False alarm (temporarily), this change doesn't seem to have actually
worked. I'll look into it later when I have more time.
Stuart.
On 2/15/06, Stuart Ballard [EMAIL PROTECTED] wrote:
I just found and partially fixed a longstanding bug in japi - it was
ignoring members declared in non-public superclasses. Apparently these
members *are* accessible. I noticed this because the comparison
between jdk14 and jdk15 was reporting a bunch of methods in
StringBuffer as missing, because in jdk15 these were moved to a
non-public superclass shared between StringBuffer and StringBuilder.
I'm rerunning now with this bug fixed; if it causes any changes to the
results for Classpath, there'll be a diff email shortly.
There is one remaining problem that isn't quite so trivial to fix: a
field that's declared in a non-public superclass should be treated as
if it were declared in the first public subclass of that class (in the
cases where the declaring class matters). Theoretically, this could
produce erroneous results. If the new runs introduce any errors
claiming that fields ought to be declared in non-public classes,
please ignore those errors until I can fix the japi bug, at which
point they'll either go away or give a correct location where the
fields should be declared.
There's actually a really really obscure corner case where the fact
that it's declared in a non-public superclass might actually matter:
class Super {
public static int value;
}
public class Sub1 extends Super {
}
public class Sub2 extends Super {
}
public void test() {
Sub1.value = 1;
System.out.println(Sub2.value);
}
However, since Super isn't part of the public API at all, I can't
think of any way for Japi to represent the fact that Sub1.value and
Sub2.value are actually the same field without ever mentioning (or
knowing about) the nonpublic class. Especially since it's only
actually an issue if more than one public subclass exists. Any
suggestions?
Stuart.
--
http://sab39.dev.netreach.com/
--
http://sab39.dev.netreach.com/
