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