Possible BUG in VAJ 3.5.3 : Inner class

[Desai Sandeep]

Hi,
There seems to be a difference in compilation of Java code by using JDK 1.3 and VisualAge for Java, Professional Edition, Version 3.5.3
<pre>
package A;
public class Parent {
protected void parentMethod() {
System.out.println("Hello");
}
}
package B;
import A.Parent;
public class Child extends Parent {
public void callParent() {
parentMethod();
}
public void callParentViaInner() {
Object obj = new Object() {
public void callParent() {
Child.this.parentMethod(); //(1)
};
};
}
}
</pre>
When I use the Sun JDK 1.3 version, the above code compiles with out errors.
However, using the VisualAge for Java compiler, I get an error at Line (1).
<pre>
void callParentViaInner() 1 Errors, 0 Warnings
The method parentMethod invoked for type B.Child with arguments () is not visible
</pre>
Is this a BUG in the IDE or am I missing something?
Please advise!
Sandeep

[John Dale]

It might be interesting to see if you have the same problem running with a Sun JDK 1.2.2.

[Desai Sandeep]

I donot have Sun JDK 1.2.2 on my machine.However, I believe it shouldn't make a difference.From what I remember, if the local inner class has to invoke the method of the enclosing class, it has to be in the format EnclosingClass.this.method().
-- Sandeep

[John Dale]

Compliers sometimes have bugs. I've seen one or two in JDK 1.3.0. I suspect that you are more likely to get this kind of difference between releases (1.2.2 vs 1.3) than between two vendors' releases of the same compiler version.
I think this has more to do with the inner class accessing the protected method of the superclass from a different package, more than with the use of Class.this.
I suppose you've found a workaround, like giving the derived class a private method to call the protected member of the superclass, and having the inner class call that method in the derived class instead of calling the protected member of the superclass directly.

[Desai Sandeep]

John,
It is strange when you find a award winning product not adhering to the Java Language specification (JLS).
Yes, this is to do more with protected access modifier than inner classes.
In any case, I think in JDK 1.2.2 and JDK 1.3, this code should compile without errors.
If you look at the code snipplet, the callParent() in the Child class which calls the protected parentMethod() doesn't give any problems.This is as per JLS which says , a subclass can access a protected method defined in its superclass irrespective of the package in which they have been defined.
Also the JLS goes on to say that the local class defined in the subclass has access to the superclass protected method.This is what the VAJ compiler doesn't seem to agree on; the protected methods defined in the enclosing superclass is not visible in the local class!

The workaround as you have suggested is to call Child.this.callParent(), where callParent() is defined in the Child class itself.
Thank you for your views,
Sandeep
PS : BTW, should we report this BUG to IBM?If yes, how do we do it?
-- Sandeep
[This message has been edited by Desai Sandeep (edited July 19, 2001).]

[John Dale]

See Sun bug report 4269441. It's a close relative to 4333902 and 4116802, which they say is present in all versions of 1.2.2.
Bug report 4269441 gives the same workaround we discussed.
Even if the IBM compiler didn't reject the form you want to use, you would not want to use a construct that fails in other versions of 1.2.2, and for which such an easy, safe workaround is available, would you?
As I understand it, for some problems of this general sort, some runtimes may not allow access even if some compilers generate the code. But I've not seen if that applies in this situation.
[This message has been edited by John Dale (edited July 19, 2001).]

[Desai Sandeep]

Hi John,
As per the Bug report on 4269441 in JDK 1.2.2, Child.this.method() will compile without any problems.Although, the bug report says JDK 1.3 Beta Version will give errors while compilation, this has been fixed in tne production release of JDK 1.3.I say this, since I didnot get any compilation errors while compiling the above code snipplet in Sun JDK 1.3 Production release.
This means, Sun believes that Child.this.method() is the correct way to call a protected method defined in the base(super) class, in the inner class of the enclosing subclass.
I have also tested the same using the Oracle JDK 1.2.2 version with success.Since VAJ 3.5.3 is also based on JDK 1.2.2 version, I suppose IBM has missed this feature in their JDK implementation.If IBM removes this bug, we wouldn't require the workaround that we have discussed.

Thank you for your views,
Sandeep
[This message has been edited by Desai Sandeep (edited July 22, 2001).]

[John Dale]

You are welcome to my views, even to share them. :-)
I'll use the technique suggested in the workaround section of Sun bug report 4296441 when writing code that might need run on 1.2.x (or 1.1.x) machines, for the reasons stated before. That technique is to have the inner class call a method of enclosing class that accesses the protected member of superclass. I know we disagree on this.
For a discussion of the history of this in the JLS, see http://www.ergnosis.com/java-spec-report/java-language/jls-6.6.2.1-b.html .
I don't know the best way for you to report the issue to IBM. If you have a formal support arrangement, consider using that. As for informal support, I know we've both done well with ibm.software.vajava.* groups. The ibm.software.vajava.language group seems like a good place to start.
Beyond that, if you go to the IBM VisualAge Developer Domain (www.ibm.com/vadd) and check the site map, you'll see a "request a feature" for VAJ as well as other support options. Searching for feature request 651 will bring up "Improve conformance to Java Language Specification". I'm not familiar enough with the feature request database to know whether the low number of votes for this item suggests that VAJ users think VAJ language conformance is pretty good.
Chasing this down has been a good way to learn about some useful resources.
Again, I doubt that the IBM Applications Servers forum is the best place to get a broad response for questions about VAJ.
Cheers.
[This message has been edited by John Dale (edited July 22, 2001).]

[Desai Sandeep]

John,
Thanks for the reply.
I found the newsgroup you mentioned at IBM site.I wish it was a discussion forum and not a newsgroup.Do they have any discussion forum like JavaRanch?
Yes, VADD site is very good.I am a Professional Level subscriber of VADD and have found the CD and the web information very helpful.
Let's hope IBM has taken care of this BUG in the latest version of VAJ 4.0.Did you get a chance to work on it?
-- Sandeep

[John Dale]

Those newsgroups are the best informal support I've seen. It appears that several VAJ team members participate. I don't know of any other discussion forums. If the problem is that you are not set up to post on newsgroups, I'll be happy to post your question/report on this topic on your behalf.
I've not tried VAJ 4.0 yet, since 3.5.3 is close enough for my purposes. But from looking over the stuff I've already told you about and from reading the newsgroup posts about the differences between VAJ 3.5.3 and 4.0, I wouldn't bet it's changed in VAJ 4.0.
Personally, as a VAJ user, I'd rather see the VAJ staff spend their time on stuff other than fixing this, so I've not tried to report it. But I've told you the ways I might go about it if I did want to report it.

[Desai Sandeep]

John,
I agree with you on this.
As Developers, we would like VAJ team to spend more time on enhancing the product, as long as we know the workaround for the BUG we find!
Having said that, I would like the BEST Java IDE to atleast adhere to the Reference Implementation (RI) of the JDK they are implementing.
These kind of stuff can become very discomforting in situations when a development team is working on different development environments.It is enough to create confusion in the minds of the Developers!Imagine a Developer doing refactoring in a non-VAJ IDE, decides to removes our VAJ workaround, tests it and says everything is fine.It could become very clumsy.So the least one expects is IBM document all this somewhere so that we Developers are aware about it!
-- Sandeep