Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Generics and ClassLoaders

Reply
Thread Tools

Generics and ClassLoaders

 
 
Josef Garvi
Guest
Posts: n/a
 
      04-29-2005
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
 
Reply With Quote
 
 
 
 
John C. Bollinger
Guest
Posts: n/a
 
      04-29-2005
Josef Garvi wrote:

> 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.

--
John Bollinger
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
 
 
 
Josef Garvi
Guest
Posts: n/a
 
      04-29-2005
John C. Bollinger wrote:
>
> 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
 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      04-29-2005
Josef Garvi <(E-Mail Removed)> wrote:
> 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
example, Class<? extends LinkHandler>, and the problem would still
apply.

> 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
 
Reply With Quote
 
Josef Garvi
Guest
Posts: n/a
 
      04-30-2005
Chris Smith wrote:
> Josef Garvi <(E-Mail Removed)> wrote:
>
>>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
> 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.


>>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.


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Plug-in classloaders and class path rexguo@h.o.t.m.a.i.l.c.o.m Java 2 06-22-2005 08:31 AM
plugins, api and classloaders ittay.dror@gmail.com Java 3 02-07-2005 04:44 PM
Tomcat and classloaders Erik Berglund Java 7 09-18-2004 09:48 PM
RMI, singletons and multiple classloaders in Weblogic Michael Brown Java 3 08-09-2004 08:49 PM
ClassCastException and ClassLoaders Luther Baker Java 3 09-10-2003 02:56 AM



Advertisments