JDK-4018532 : no runtime check of accessibility of an invoked method
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.1
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_2.4
  • CPU: sparc
  • Submitted: 1996-12-10
  • Updated: 1997-07-22
  • Resolved: 1997-07-22
Related Reports
Duplicate :  
Description

Name: swC45995			Date: 12/10/96


The following assertion do not holds:

Let C be the class containing the method invocation, and let T be the class or interface that contained the method being invoked, and m be the name of the method, as determined at compile time. ...

The virtual machine must also insure, during linkage, that the type T and 
the method m are accessible. ...

If either T or m is not accessible, then an IllegalAccessError occurs
(#15.11.4.3 Check Accessibility of Type and Method)

Thus, compilation of the source file:

public class test
{
	public static void main(String argv[])
	{
		int res;

		try {
			res = auxiliary.cipher();
		} catch (IllegalAccessError e) {
			System.out.println("pass");
		}
		System.out.println("fail");
	}
}

class auxiliary
{
	public static int cipher()
	{
		return 777;
	}
}

followed by compilation of the modified version of the latter class:

class auxiliary
{
	private static int cipher()
	{
		return 777;
	}
}

and subsequent execution of the test produces such output:

novo40% javac test.java
novo40% javac auxiliary.java
novo40% java test
fail


instead of expected:

novo40% javac test.java
novo40% javac auxiliary.java
novo40% java test
pass
======================================================================

Comments
EVALUATION Li Gong looked at this and thinks it is a serious bug. I checked that this fails on 1.0.2 also. david.bowen@Eng 1997-01-24 ---------------------------------------------------------------------------- It was decided that the rather than close this up tight for JDK1.1 we should give people time to use the new compiler (which doesn't rely on this bug when it inlines public methods that call private methods), and only then (e.g. in JDK1.1.1 close the hole in the runtimes. Otherwise, there may be a whole pile of class files compiled with JDK1.0.2 that will suddenly stop working. We also need to figure out how many such class files there are out there. I'm downgrading this to P3 because we won't fix it for JDK1.1, but we don't want to forget it for JDK1.1.1. peter.kessler@Eng 1997-01-28
28-01-1997