2013/5/11 Konstantin Preißer <verlag.preis...@t-online.de>:
> Hi Konstantin,
>
>> -----Original Message-----
>> From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
>> 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%/src.zip. 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
