Re: [OT] Querstion about Class.forName() re. ClassLoaders
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
RE: [OT] Querstion about Class.forName() re. ClassLoaders
Hi Konstantin, -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Saturday, May 11, 2013 2:46 PM 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()). Yes, when I use new Foo() instead of Class.forName(Foo).newInstance() then I get the same result: It uses the ClassLoader of the class that implements the method. I agree that in this case it is a documentation issue. 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 Thanks! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Querstion about Class.forName() re. ClassLoaders
2013/5/10 Konstantin Preißer verlag.preis...@t-online.de:
Hi all,
I apologize for being completely off-topic (this question has nothing to do
with Tomcat), but I thought there may be some guys here that are experts in
class loading and are able to answer my question.
You probably know the method java.lang.Class.forName(String name) which
returns a class object from the given name. The JavaDoc (Java 7) of this
method says:
Returns the Class object associated with the class or interface with
the given string name. Invoking this method is equivalent to:
Class.forName(className, true, currentLoader)
where currentLoader denotes the defining class loader of the current
class.
While this description may be a bit ambiguous about what current class
means here, the JavaDoc of Class.forName(String name, boolean initialize,
ClassLoader loader) makes it clearer by stating:
For example, in an instance method the expression:
Class.forName(Foo)
is equivalent to:
Class.forName(Foo, true, this.getClass().getClassLoader())
So, shouldn't this mean that I get the same result/behavior when writing this
code:
public void doSomething() throws ClassNotFoundException {
Class? clazz = Class.forName(foo.Bar);
// do something...
}
Instead of this one:
public void doSomething() throws ClassNotFoundException {
Class? clazz = Class.forName(foo.Bar, true,
this.getClass().getClassLoader());
// do something...
}
or did I misunderstand something?
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?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Querstion about Class.forName() re. ClassLoaders
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). Thanks! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
