We have appearantly run across a fairly serious bug in the JVM,
with regards to runtime type security.

Basically it is possible to get runtime public access to values that
have been declared as private in their .class file.

Given the following source:

(and the following compilation order)

PrivateO.java

public class PrivateO
{
public int value;

public PrivateO()
    {
    value=10;
    }
}

compile PrivateO.java

and the following src

class PrivateFiend
{

public static void main(String args[])
    {
    PrivateO obj=new PrivateO();

    System.out.println("The value of PrivateO's private variable is: "+obj.value);

    }

}

and compile PrivateFiend.java

and *NOW* reedit PrivateO.java and recompile it as it appears below

public class PrivateO
{
private int value;

public PrivateO()
    {
    value=10;
    }
}

Since the PrivateFiend.class file has not been regenerated, it runs
even tho PrivateO's value field is now declared private in it's own
PrivateO.class file, thus it
would appear that the JVM does *NOT* perform a runtime access flag
check, much less verify that the field is being accessed according
to the access flags that is has at runtime!

(I did make double sure that the .class files were not being
recompiled under the covers by the JVM, they are not, as the
time stamps have not changed in the file system after running the
test program)

Hopefully this is enough info...

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

Use the -verify switch to the VM.

The bug report is correct.
Some day the offending sort of 1.0 code (non-applets which were compiled -O)
will be rare in the field, and we can make "java -verify" the default,
with "java -noverify" a compatibility option.

Apparently, this has been fixed in Java SE 6.