Generics and ClassLoaders

[Josef Garvi]

Assuming:
String myClass = "some.package.SomeClass";
ClassLoader aClassLoader = someClassLoader;


This statement provokes a type-safety warning when using c.newInstance():
Class c = aClassLoader.loadClass(myClass);

This statement gives an error:
Class<LinkHandler> c = aClassLoader.loadClass(myClass);

This statement gives a warning:
Class<LinkHandler> c = (Class<LinkHandler>)
aClassLoader.loadClass(myClass);


How should I load the class if I want to avoid the error message?
Or has this become a "don't" in Java 5.0?

--
Josef Garvi

"Reversing desertification through drought tolerant trees"
http://www.eden-foundation.org/

new income - better environment - more food - less poverty

 

[John C. Bollinger]

Assuming:
String myClass = "some.package.SomeClass";
ClassLoader aClassLoader = someClassLoader;


This statement provokes a type-safety warning when using c.newInstance():
Class c = aClassLoader.loadClass(myClass);

This statement gives an error:
Class<LinkHandler> c = aClassLoader.loadClass(myClass);

This statement gives a warning:
Class<LinkHandler> c = (Class<LinkHandler>)
aClassLoader.loadClass(myClass);


How should I load the class if I want to avoid the error message?
Or has this become a "don't" in Java 5.0?

Look at the Javadocs: ClassLoader.loadClass(String) returns a Class<?>.
You can assign it to a variable of that type without warning. This
makes complete sense, because there is no general way to determine at
compile time what type the method will load a Class for. The class
might not even be available to the compiler. Making any assumption
about what class has been loaded is inherently a type safety problem
(which is nothing new; it's just that Java 5 produces warnings for it,
and previous compilers didn't). You should load the class per your last
example, and put up with the type safety warning that you will get.

 

[Josef Garvi]

Look at the Javadocs: ClassLoader.loadClass(String) returns a Class<?>.
You can assign it to a variable of that type without warning. This
makes complete sense, because there is no general way to determine at
compile time what type the method will load a Class for. The class
might not even be available to the compiler. Making any assumption
about what class has been loaded is inherently a type safety problem
(which is nothing new; it's just that Java 5 produces warnings for it,
and previous compilers didn't). You should load the class per your last
example, and put up with the type safety warning that you will get.

Yep, returning Class<?> makes perfect sense, but warning me when I cast it
to Class<LinkHandler> less so - after all I am explicitly casting. Sooner
or later, a runtime error will anyway occur if I get it wrong. But I guess
I am warned because erasure implies that the runtime cast error can not be
detected at that particular line of code, should the types not match.

I'd really like to get rid of the compiler warnings when
I'm doing things right - otherwise i'll either start ignoring them, or turn
them off - neither of which is likely to improve my code's type safety!

--
Josef Garvi

"Reversing desertification through drought tolerant trees"
http://www.eden-foundation.org/

new income - better environment - more food - less poverty

 

[Chris Smith]

Yep, returning Class<?> makes perfect sense, but warning me when I cast it
to Class<LinkHandler> less so - after all I am explicitly casting.

In the particular instance of casting to Class<LinkHandler>, you
probably shouldn't be doing this anyway. If you can refer to the class
lexically from the code, then you should just use a class literal
expression instead of ClassLoader.loadClass to obtain the reference.
However, you might wish to cast the reference to something else, for

I'd really like to get rid of the compiler warnings when
I'm doing things right - otherwise i'll either start ignoring them, or turn
them off - neither of which is likely to improve my code's type safety!

It's unfortunately not really possible to develop with generics and
warnings for unchecked casts enabled, without just ignoring certain
compiler warnings.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Josef Garvi]

In the particular instance of casting to Class<LinkHandler>, you
probably shouldn't be doing this anyway. If you can refer to the class
lexically from the code, then you should just use a class literal
expression instead of ClassLoader.loadClass to obtain the reference.
However, you might wish to cast the reference to something else, for
example, Class<? extends LinkHandler>, and the problem would still
apply.

Yes, Class<? extends LinkHandler> is what I should cast it to.
It's a plugin system, so I can't no the precise class at compile time.

It's unfortunately not really possible to develop with generics and
warnings for unchecked casts enabled, without just ignoring certain
compiler warnings.

Ok.
I've returned to just using Class<?> and using a cast at newInstance().
That way, at least I don't need to get bugged by the warning.

--
Josef Garvi

"Reversing desertification through drought tolerant trees"
http://www.eden-foundation.org/

new income - better environment - more food - less poverty