tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: [OT] Querstion about Class.forName() re. ClassLoaders
Date Sat, 11 May 2013 12:45:56 GMT
2013/5/11 Konstantin Prei├čer <>:
> Hi Konstantin,
>> -----Original Message-----
>> From: Konstantin Kolinko []
>> Sent: Friday, May 10, 2013 11:46 PM
>> Yes, the same.
>> BTW, Oracle JDKs come with source code for their public classes, On
>> Windows that is %JAVA_HOME%/ Do you have such file?
> Thank you for your answer. Yes, I have that file and I looked there, but that Class.forName(String)
method calls a native method for which I couldn't find the source.
> I asked this question because the above is not what is implemented by Sun/Oracles JRE
(I tested with Windows 32-bit versions of JRE 1.7.0_21, Java 8 EA (b88) and Java 5).
> It seems that in Oracles Java, Class.forName(String) uses the ClassLoader of the class
which implements the method that makes the call to Class.forName(), not the ClassLoader of
the class on whose instance the method is called (which is the one used when calling getClass().getClassLoader()).
This can make a difference e.g. if the Class with that method has a subclass and you call
the method on an instance of the subclass (which is what I experienced with a Eclipse RCP
app which uses a ClassLoader hierarchy for plugins).
> However, since the bug exists in current Java 1.7.0_21 (from 2013) and even in Java 1.5.0
(2004), I wondered if nobody else noticed this discrepancy between the JavaDoc and the actual
implementation or maybe if Sun/Oracle just doesn't fix such bugs. (I already submitted a bug
report on December 1, 2012, but did not yet receive a response - so I wanted to make sure
my understanding was correct).

Nice catch.
But I think it is just a documentation issue.

I think documentation should be better here: Looking at 7u21, it uses
two different wordings
a) in description of Class.forName(String, boolean, ClassLoader):
an example with "this.getClass().getClassloader()"
This one is wrong.

b) in description of Class.forName(String)
"the defining class loader of the current class."
This is correct, but one would better clarify what "current class"
means here, as it is ambiguous.

Java Language Specification (3rd edition) uses the term "the defining
class loader" (of a class) in several places, e.g. chapter 15.8.2
Class Literals.

Two points:
1. I expect  Class.forName("Foo").newInstance() to give the same
result as "new Foo();"

I think the current behaviour is more consistent. (Relying on the
class which bytecode is executed, instead of this.getClass()).

2. Implementation relies on method ClassLoader.getCallerClassLoader(),
which looks up stack frames in JVM.

You cannot change this method itself, as it is used in security checks
in many places. To change the behaviour one would need to create a
different method.

BTW, if you look for oddities,  Class.newInstance() is a legacy method
that can throw a non-declared checked exception "as is", without
wrapping it in InvocationTargetException. (The method is there @since
1.0 and InvocationTargetException is @since 1.1)

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message