On Fri, 5 Dec 2003, Mark Taylor wrote:
> > Mark,
> >
> > Attached is the build log for STARJAVA, VOtable failed.
>
> this is interesting. Compiler behaviour has changed between 1.4.1_03
> and 1.4.2_02. Reduced to a simple case:
>
> public abstract class Outer {
> private void doStuff() {}
> private class Member extends Outer {
> public void doStuff( Object obj ) {
> doStuff();
> }
> }
> }
>
> compiles using 1.4.1 but with 1.4.2 I get:
>
> Outer.java:7: doStuff(java.lang.Object) in Outer.Member cannot be applied to ()
> doStuff();
> ^
>
> I reckon this is a new bug introduced at 1.4.2 - private members should
> be accessible within the class in which they are declared. Here the
> public method declaration in the nested class is hiding the private
> declaration in the enclosing class with the same name but a different
> signature.
>
> JLS 6.6.1 says:
>
> Otherwise, if the member or constructor is declared private,
> then access is permitted if and only if it occurs within the body
> of the top level class (ยง7.6) that encloses the declaration of
> the member.
>
> Anyone reckon the new behaviour is correct and the old one was a bug?
> Unless they do I'll report it to Sun.
>
> In the mean time I've tweaked the source of the offending class in
> the VOTable package so that it doesn't hit this bug.
Hi Mark,
I think this is related to bug report:
http://developer.java.sun.com/developer/bugParade/bugs/4905020.html
for 1.4.2, which has the evaluation:
"The compiler is right to reject this; private methods are not inherited,
therefore the method being called is not a member of the inner class and
should not be found by the compiler. Previous compilers accepted this
code erroneously."
The solution is just to use "super.doStuff()" (which occurred to me, but
reading the analysis now looks odd too).
Peter.
|