On 12 May 2006, at 09:10, Charles Miller wrote:
It's not reflection: you're confusing IllegalAccessException and
IllegalAccessError.
For any non-Java nerd still listening in: there are two fundamental
types of "Throwable" exception-conditions in Java: Exceptions and
Errors[1]. Exceptions represent application-level conditions --
things an application is likely to be able to recover from, like
network timeouts, trying to read beyond the end of a file, and so
on. Errors, on the other hand, represent VM-level problems that an
application can't really do anything about, like running out of
memory, not finding a required native library, or encountering
corrupted class files.
IllegalAccessException happens when reflective code attempts to
access some field or method it's not supposed to. Because it's a
result of reflection, it's considered an application-level problem
and it's assumed your code can recover gracefully.
Amusingly enough, you can get around most IllegalAccessExceptions
in java just by calling {field|method}.setAccessible(true). So long
as there's no explicit SecurityManager installed, as soon as you've
done that you're free to modify the field or call method to your
heart's content[2].
IllegalAccess_Error_, on the other hand, happens when some non-
reflective code issues a bytecode instruction that attempts to
access a field or method it shouldn't be able to see. If you look
at its class hierarchy, the meaning of the class is pretty clear:
IllegalAccessError is a subclass of IncompatibleClassChangeError,
which is a subclass of LinkageError. Because this is a problem at
the bytecode/classloading level, and literally something that could
happen on _any_ method-call or field-access, it's flagged as an error.
The Error generally occurs when class A has been compiled against a
version of class B where a method is public, but that method is
private in the version of the same class it encounters at runtime.
This sort of thing happens quite often in Java, you're frequently
stuck in "jar file hell", in a twisty turny maze of library
interdependencies, all with slightly different version numbers.
More about the circumstances of IllegalAccessError here:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/
ConstantPool.doc.html
Dynamic classloading isn't really at fault here. There are all
sorts of pits you can fall into when you start rolling your own
classloader (the Java webapp I develop supports dynamic runtime-
deployable plugins, and the classloading issues are a HUGE
headache), but IllegalAccessError isn't one of them.
Charles
[1] Exceptions are further divided into checked exceptions and
runtime exceptions, but that's beyond the scope of this email
[2] See also: http://www.javaspecialists.co.za/archive/
Issue014.html
Thanks for clearing this up Charles.
I've created another example that uses a class loader to load the
classes, and this time, it throws an IllegalAccessError just like
Tomcat does:
Loading class: /Users/stephen/data/dev/classloader/myclass/
somepackage/MyTest.class
Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/
Runnable.class
Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/
Object.class
Loading class: /Users/stephen/data/dev/classloader/myclass/
somepackage/MyData.class
Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/
System.class
Exception in thread "main" java.lang.IllegalAccessError: tried to
access method somepackage.MyData.getName()Ljava/lang/String; from
class somepackage.MyTest
at somepackage.MyTest.run(MyTest.java:15)
at classloader.Main.main(Main.java:26)
Java Result: 1
This error is thrown irrespective of the -verify flag. So it looks
like using a classloader causes the VM to perform verification,
whether or not the "verifier" was enabled. Michael Silk made a
similar statement earlier in this thread. Would you agree?
PoC code below:
package classloader;
public class Main {
public Main() {
}
public static void main(String[] args) {
//Illegal Access Error
try {
CustomLoader cl = new CustomLoader(System.getProperty
("user.dir")+"/myclass/");
Class myClass = cl.loadClass("somepackage.MyTest");
Runnable r = (Runnable)myClass.newInstance();
r.run();
} catch (Exception e) {
e.printStackTrace();
}
}
}
package classloader;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
public class CustomLoader extends ClassLoader {
private String path = null;
public CustomLoader(String path) {
this.path = path;
}
private byte[] getBytes( String filename ) throws IOException {
File file = new File( filename );
long len = file.length();
byte raw[] = new byte[(int)len];
FileInputStream fin = new FileInputStream( file );
int r = fin.read( raw );
if (r != len)
throw new IOException( "Can't read all, "+r+" != "+len );
fin.close();
return raw;
}
public Class loadClass( String name, boolean resolve )
throws ClassNotFoundException {
Class clas = null;
String fileStub = name.replace( '.', '/' );
String classFilename = path+fileStub+".class";
System.out.println("Loading class: "+classFilename);
File classFile = new File( classFilename );
try {
byte raw[] = getBytes( classFilename );
clas = defineClass( name, raw, 0, raw.length );
} catch( IOException ie ) {
}
if (clas==null) {
clas = findSystemClass( name );
}
if (resolve && clas != null)
resolveClass( clas );
if (clas == null)
throw new ClassNotFoundException( name );
return clas;
}
}
In current directory create a folder ./myclass/somepackage with the
following two files:
package somepackage;
public class MyData {
private String name;
public MyData() {
name = "No one can read me";
}
public String getName() {
System.out.println("private method called");
return (name);
}
}
package somepackage;
public class MyTest implements Runnable {
MyData m;
public MyTest() {
m = new MyData();
}
public void run() {
System.out.println(m.getName());
}
}
Compile both these classes, then change the MyData.getName method to
private access, and recompile MyData.
Stephen
-------------------------------------------------------------------------
Sponsored by: Watchfire
Methodologies & Tools for Web Application Security Assessment
With the rapid rise in the number and types of security threats, web
application security assessments should be considered a crucial phase in
the development of any web application. What methodology should be
followed? What tools can accelerate the assessment process?
Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9h
--------------------------------------------------------------------------
