ID: Q156912
The information in this article applies to:
The Java Language Compiler (jvc) incorrectly compiles code that violates field visibility rules according to the Java specification. If a sub- classed object (S) is derived from a base class (B) in another package that has a protected member variable (ld) and class S tries to access a member via a qualified name of Q.ld, access is permitted only if Q is S or a subclass of S. If Q is the base class of S, then access should not be permitted and an error should be generated. JVC compiles code that violates this field visibility rule without generating any warnings or errors.
Microsoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article. This problem has been fixed in Visual J++ 1.1.
Steps to Reproduce Problem
The following sample code demonstrates an example where the qualified name Q.ld has Q being a superclass of S, instead of a subclass. According to the Sun specification 6.6.2, the expression a.myProtectedVariable is not valid since it is defined in another package with protected field visibility:
// aProtectedPackage.myBaseClass
package aProtectedPackage;
public class myBaseClass {
protected int myProtectedVariable;
}
// derivedClass
import aProtectedPackage.myBaseClass;
class derivedClass extends myBaseClass {
void test(myBaseClass a) {
this.myProtectedVariable=1;
a.myProtectedVariable=0; // this should generate an error
// according to 6.6.2, but JVC does not
// generate any warnings.
}
}
For the latest Knowledge Base articles and other support information on Visual J++ and the SDK for Java, see the following page on the Microsoft Technical Support site:
http://support.microsoft.com/support/visualj/
http://support.microsoft.com/support/java/
Keywords : kbCommandLine
Version : 1.0
Platform : WINDOWS
Issue type : kbbug
Solution Type : kbfixLast Reviewed: November 12, 1998