Hi Konstantin,
> -----Original Message-----
> From: Konstantin Kolinko [mailto:[email protected]]
> 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: [email protected]
For additional commands, e-mail: [email protected]
