Microsoft KB Archive/156912

= FIX: Protected Members Accessible to Subclass in Other Package =

Article ID: 156912

Article Last Modified on 5/12/2007

-

APPLIES TO


 * Microsoft Visual J++ 1.0 Standard Edition

-



This article was previously published under Q156912



SYMPTOMS
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.



STATUS
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. } }

