Java: Inner classes can't see outer class protected functions/variables
Kerry Shetline
or using Visual Cafe (which I wanted to dump in favor of CodeWarrior).
My first attempts to port to CodeWarrior are producing nothing but an
awful mess. Dozens of places where inner or anonymous classes access
outer class functions, I get the error:
No method matching foo() found in inner class
com.mycompany.mypackage.X
Dozens of places where inner or anonymous classes access outer class
variable, I get the error:
Variable bar in class com.mycompany.mypackage.Y not accessible from
inner class
Having googled this problem, the only advice I found was a rather lame
work-around, suggested about two years ago, of making everything that
causes this kind of problem public. Two years later, I'm hoping
there's something better I can do here.
One possible difference between my situation and the old
comp.os.ms-windows.programmer.tools.misc post I found is that my outer
classes are in a different package than those outer classes'
superclasses, and the inner classes are sometimes referencing members
of their outer classes' superclasses.
Regardless, AFAIK this is all perfectly valid Java code. Sun's javac
for Java 1.3.1 or 1.4.1 doesn't have any problems compliling this code
whatsoever.
MW Ron
ke...@shetline.com (Kerry Shetline) wrote:
Can you make a simple example, We should do any valid code, so it is
likely a setup problem in your project of something. I'm not a Java
expert so I need more to go on. A project and sources where I can
build and see it would be very helpful. It is almost impossible for us
to try to re-create this as we would not make the same error.
Ron
--
Get printed CodeWarrior Documentation (limited selection)
And all the latest versions of CodeWarrior Manuals
http://www.metrowerks.com/MW/Support/dev_resources/default.htm
Ron Liechty - MW...@metrowerks.com - http://www.metrowerks.com
Kerry Shetline
> Can you make a simple example, We should do any valid code, so it is
> likely a setup problem in your project of something. I'm not a Java
> expert so I need more to go on. A project and sources where I can
> build and see it would be very helpful. It is almost impossible for us
> to try to re-create this as we would not make the same error.
You can find a ZIP file of a sample project at:
http://www.shetline.com/codewarrior/TestInheritedAccess.zip
This code compiles just fine using javac from the command line. My
first guess about what CW is doing wrong when it tries to compile this
code is that when it tries to compile an inner class, it's only
considering the intra-package visibility granted by the "protected"
class, but not the subclass visibility, perhaps because an inner class
is not truly a subclass of its outer class's superclass (there's a
mouthful!).
At any rate, an inner class should be granted visibility of anything
that's visible to its outer class -- and javac does permit just that,
while CW doesn't seem to be doing so.
----------------- foo\HelloApp.java -----------------
package foo;
import bar.*;
public class HelloApp extends HelloBase
{
static public void main(String[] args)
{
HelloApp ha = new HelloApp();
ha.start();
}
public void start()
{
HelloInner hi = new HelloInner();
hi.sayHello();
}
private class HelloInner
{
public void sayHello()
{
System.out.println("Hello, World: x = " + x);
System.out.println("Once more, with feeling: x = " + getX());
}
}
}
----------------- bar\HelloBase.java -----------------
package bar;
public class HelloBase
{
protected int x = 42;
protected int getX()
{
return x;
}
}
-------------------------------------------------------
Using CW, the above code only complies if I change both "protected"
access modifiers in HelloBase to "public". Using javac like this:
javac bar\HelloBase.java foo\HelloApp.java
...however, and both Java files compile without error. In addition:
java foo\HelloApp
...also runs the resulting class files without any problems.
Using the original protected access, CW produces these error messages:
Line 25: Variable x in class bar.HelloBase not accessible from inner
class foo.HelloApp
Line 26: No method matching getX() found in class foo.HelloApp.
(You have to comment out line 25 to see the error given for line 26.)
MW Ron
>MW Ron <mw...@metrowerks.com> wrote:
>> Can you make a simple example, We should do any valid code, so it is
>> likely a setup problem in your project of something. I'm not a Java
>> expert so I need more to go on. A project and sources where I can
>> build and see it would be very helpful. It is almost impossible for us
>> to try to re-create this as we would not make the same error.
>
>You can find a ZIP file of a sample project at:
>
> http://www.shetline.com/codewarrior/TestInheritedAccess.zip
>
>This code compiles just fine using javac from the command line. My
>first guess about what CW is doing wrong when it tries to compile this
>code is that when it tries to compile an inner class, it's only
>considering the intra-package visibility granted by the "protected"
>class, but not the subclass visibility, perhaps because an inner class
>is not truly a subclass of its outer class's superclass (there's a
>mouthful!).
>
>At any rate, an inner class should be granted visibility of anything
>that's visible to its outer class -- and javac does permit just that,
>while CW doesn't seem to be doing so.
>
This is a bug in CodeWarrior for Mac Java.
Kerry Shetline
>>At any rate, an inner class should be granted visibility of anything
>>that's visible to its outer class -- and javac does permit just that,
>>while CW doesn't seem to be doing so.
>>
>
> This is a bug in CodeWarrior for Mac Java.
From your e-mails to me (which weren't posted here), it sounds like
this bug also exists on Windows (which is where I was seeing it), but
that the difference is that on Windows a patched compiler is available,
whereas for Mac, there is no fix currently.
From what you said about the patched compiler on Windows, even that's
not a total fix, but a tradeoff -- no compilation bugs regarding the
above issue, but having to use a slower compiler running as interpreted
code rather than compiled native code.
Since you characterized this buf as a "long-standing" Java compiler bug,
I sure hope someone's planning on ending the "long stand" sometime soon!
I work on both Windows and OS X, and would like to know that my Java
compilation will be both fast and platform independent.
-Kerry
MW Ron
Kerry Shetline <ke...@shetline.com> wrote:
>MW Ron wrote:
>>>At any rate, an inner class should be granted visibility of anything
>>>that's visible to its outer class -- and javac does permit just that,
>>>while CW doesn't seem to be doing so.
>>>
>>
>> This is a bug in CodeWarrior for Mac Java.
>
> From your e-mails to me (which weren't posted here), it sounds like
>this bug also exists on Windows (which is where I was seeing it), but
>that the difference is that on Windows a patched compiler is available,
>whereas for Mac, there is no fix currently.
Apparently it is not fixed on the Windows Desktop tools either only on
the Java PDA version.
> From what you said about the patched compiler on Windows, even that's
>not a total fix, but a tradeoff -- no compilation bugs regarding the
>above issue, but having to use a slower compiler running as interpreted
>code rather than compiled native code.
>
>Since you characterized this buf as a "long-standing" Java compiler bug,
>I sure hope someone's planning on ending the "long stand" sometime soon!
>I work on both Windows and OS X, and would like to know that my Java
>compilation will be both fast and platform independent.
Thank you for your patience.