japi and protected field declaring classes

[Stuart Ballard]

As I mentioned in my blog, I added support to japitools for checking
the declaring class of fields. The example of code I used to justify
this was:

Implementation 1:
public class Super {public int foo;}
public class Sub extends Super {}

Implementation 2:
public class Super {public int foo;}
public class Sub extends Super {public int foo;}

Client code:
void incFoo(Super sup) {sup.foo++;}
Sub x = new Sub();
incFoo(x);
System.out.println(x.foo);

I still think this is a valid concern and it's right for japitools to
catch it, but when I actually saw what happened as a result of this in
the nightly comparisons, I started to have my doubts over whether the
check I implemented is over-zealous.

It appears that Sun have a field numBands in java.awt.image that's
exactly like Implementation 2 above (declared in both
ComponentSampleModel and SampleModel), except that it's protected.
(someone fixed classpath to conform to this, gmane isn't helping me
find out who actually did it right now though).

The problem I'm seeing (and I feel bad for only realizing this after
someone did work based on japi's output) is that my example code to
support the claim that this difference is important to binary
compatibility only works if the field is public. If it's protected
there's no possible way to write the incFoo method to make it actually
modify the superclass's foo field.

So I'm beginning to think that the declaring class should only matter
for public fields and I should change japitools to not consider it for
protected fields. Can anyone think of a way to write code where the
declaring class *does* matter when the field is protected?

If it really doesn't matter, I'm sorry to the person who made the
awt.image fix based on this misinformation out of japi... :(

Stuart.

--
http://sab39.dev.netreach.com/