allan.jacobs@Eng 1997-10-29
Access control needs more definition. Most, but not all, access
violations are compile-time errors. The specification is mute as to
whether all access violations are compile-time errors or not.
There is a hole in the access control that cannot be fixed without a
ruling one way or the other on this question.

In the example below, the set and use of p1.p2.privatei in CMain should
not be allowed because p1.p2 has non-public class type P2. Should it
be a compile-time error or not? More fundamentally, should ANY access
violation that is detectable at compile-time be treated as an error?

algol% cat CMain.java
import pack1.P1;

public class CMain {
public static void main( String[] argv ) {
P1 p1 = new P1();
p1.p2.privatei = 3;
System.out.println (p1.p2.privatei);
}
}
algol% cat P1.java

package pack1;

public class P1 {
        public P2 p2 = new P2();
}
algol% cat P2.java

package pack1;

class P2 {
        public int privatei=0;
}
algol% setenv CLASSPATH .
algol% javac -d . P1.java P2.java
algol% javac -d . CMain.java
algol% java CMain
3


allan.jacobs@Eng 1997-11-04
A third party java test whose status is ambiguous is Modena's c0662203.
It is proprietary, but a small test code that is derived from this test
follows. Y is a public class with a protected constructor. The class
Y belongs to package cpack, so the constructor is not accessible.
The compiler javac accepts this code as legitimate. Fastjavac rejects
it.

import cpack.Y;
class T extends Y {
  public static void main(String argv[]) {
    try{
       T ot = (T) new Y(); //illegal access of protected constructor
       }catch(Exception e) { }
    }
  }
>