JDK-4026584 : package-private attributes and methods are inherited outside the
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.1
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_2.5.1
  • CPU: sparc
  • Submitted: 1997-01-17
  • Updated: 1997-09-07
  • Resolved: 1997-09-07
Related Reports
Duplicate :  
Description

Name: el35337			Date: 01/17/97

This extends the scope of bug 4023931 and explains its cause.
Javac, as well the virtual machine, allows a subclass D of C in a package pd
to inherit the package-private attributes and methods of a public class C of
another package pc. This violates encapsulation. The bug already existed in
JDK 1.02.

Symptom. Within package pd, and especially within the class D itself,
references to those inherited attributes or methods are not allowed (except
if they are redefined in D). But within package pc this is allowed. Example:
suppose the int attribute att and the int method m() have been defined with
default access in class C of package pc and are not redefined in subclass D
of package pd. The following code :

package pc;
import pd.D;

public class Main{
        public static main(String[] argv){
        D obj = new D();
        System.out.println(obj.att);
        System.out.println(obj.m());
        System.out.println(((C)obj).att);
        System.out.println(((C)obj).m());}

is sucessfully compiled (jdk 1.02 and JDK 1.1 beta2) because obj.att and
obj.m() are considered as legal references to an attribute and a field of D,
as from package pc the inherited attribute and method are visible. This
violates encapsulation. Only ((C)obj).att and ((C)obj).m should be
acceptable references in this case.

       Dyade      ###@###.###

======================================================================

Comments
WORK AROUND Name: el35337 Date: 01/17/97 ======================================================================
11-06-2004

EVALUATION We need to hash this one out thoroughly, and with the JLS authors in the loop. I tentatively like Billon's reasoning: It appears to preclude the sort of three-classes-and-two-packages problems that make this so tricky. I'm going to downgrade this to P3, because I stuck a warning (sorry everyone!) in the 1.1FCS compiler which makes it hard for a user to blithely create aliases of un-overrideable methods in other packages. Thus, it is very likely that users will not wander accidentally into this particular quagmire. The warning message is this one: no.override.access= Note: Method {0} in {1} does not override the corresponding method in {2}, which is private to a different package. (This warning is doubtless a bug, relative to the JLS. A necessary evil. Let its removal be part of the resolution of this bug report.) john.rose@Eng 1997-02-05 Note that I've modified the warning message slightly, and this is being looked at further as bug 4028226. david.stoutamire@Eng 1997-09-07 I am going to take over this bug, as it is closely related to other bugs that I am fixing. todd.turnidge@Eng 1998-07-09 Never mind. This has been closed as a duplicate and I did not notice. Reverting ownership to dps@Eng. todd.turnidge@Eng 1998-07-09
09-07-1998