Generics in 1.5, nonsense warnings?

Thread view:

changzhouwang@gmail.com - 17 Nov 2005 19:26 GMT

Isn't it strange to see a compilation warning about the following code

-------code-----
ArrayList<String> a1 = new ArrayList<String>(); ...
ArrayList<String> a2 = (ArrayList<String>)a1.clone();
-------warning (in eclipse) -----
Type safety: The cast from Object to ArrayList<String> is actually
checking against the erased type ArrayList
-------end-------

And

-------code-----
EventListener l=...;
Class<EventListener> class1 = (Class<EventListener>)l.getClass();
-------warning (in eclipse) -----
Type safety: The cast from Class<capture-of ? extends EventListener> to
Class<EventListener> is actually checking against the erased type Class
-------end-------

Without the explicit conversion, there will be compilation error, due
to the way JDK 1.5 implements generics. That's understandable.

However, I don't see why we need the warning message if there is not
possible way to get rid of it. Any comments?

-czwang

Reply to this Message

Daniel Dyer - 17 Nov 2005 19:30 GMT

> Isn't it strange to see a compilation warning about the following code
>
[quoted text clipped - 5 lines]
> checking against the erased type ArrayList
> -------end-------

...

> However, I don't see why we need the warning message if there is not
> possible way to get rid of it. Any comments?

Read up on the @SuppressWarnings annotation (and then wait for them to
actually implement it :)).

Dan.

Signature

Daniel Dyer
http://www.dandyer.co.uk

Reply to this Message

Thomas Hawtin - 17 Nov 2005 19:41 GMT

> Isn't it strange to see a compilation warning about the following code
>
[quoted text clipped - 5 lines]
> checking against the erased type ArrayList
> -------end-------

You can replace the problem code with new ArrayList<String>(a1).

> -------code-----
> EventListener l=...;
[quoted text clipped - 3 lines]
> Class<EventListener> is actually checking against the erased type Class
> -------end-------

The cast is incorrect.

> Without the explicit conversion, there will be compilation error, due
> to the way JDK 1.5 implements generics. That's understandable.
>
> However, I don't see why we need the warning message if there is not
> possible way to get rid of it. Any comments?

If your code generates no mandatory warnings, then the static type
checking will be correct. You will not get ClassCastExceptions at
unlikely places. I think that is important.

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

changzhouwang@gmail.com - 17 Nov 2005 20:01 GMT

Tom:

Thanks for your quick reply.

I agree your suggestion in the first works for ArrayList. But for other
generic class, there may not be such a constructor. My issue is that
clone() method for a generic class will always generate compilation
warning. I tried:
----
ArrayList<String> a2 = (ArrayList)a1.clone();
---
and get different warning
---
Type safety: The expression of type ArrayList needs unchecked
conversion to conform to ArrayList<String>
---

For the second example, why the cast is not correct? Indeed, this is
only way I can use EventListenerList.add(Class<T extends
EventListener> c, T l) and remove(Class<T extends EventListener> c, T
l) methods. Can you suggest a correct way to call these methods when
the listener l is often an object of a subclass of EventListener?

Thanks,
--czwang

Reply to this Message

Thomas Hawtin - 17 Nov 2005 21:06 GMT

> For the second example, why the cast is not correct?

For any particular class (within a class loader context) there is
exactly one Class object. The type of the object will be
Class<ActualClass>, which is not assignment compatible with, say,
Class<Object>.

> Indeed, this is
> only way I can use EventListenerList.add(Class<T extends
> EventListener> c, T l) and remove(Class<T extends EventListener> c, T
> l) methods. Can you suggest a correct way to call these methods when
> the listener l is often an object of a subclass of EventListener?

Something along the lines of:

listeners.add(ActionListener.class, listener);

Using getClass on the listener is the last thing you want to do. You
want to keep together, say, all ActionListeners. getClass will never
return ActionListener.class, as it is an interface and so cannot be the
runtime class of any object.

Even if you did something odd by retrieving implemented interfaces,
event listeners often implement a number of listener interfaces for
different purposes.

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Generics in 1.5, nonsense warnings?

Free Magazines