Bug 170195 - Split error/warning 'Unchecked generic type operation' into multiple settings
Summary: Split error/warning 'Unchecked generic type operation' into multiple settings
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-11 05:37 EST by John Hendrikx CLA
Modified: 2007-01-11 09:19 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Hendrikx CLA 2007-01-11 05:37:56 EST
Build ID: M20060629-1905

Steps To Reproduce:
I have the following code:

Class<FileListener> listener = Class.forName("com.xxx.SomeClass");

This results in an error: Type mismatch: cannot convert from Class<capture-of ?> to Class<FileListener>

I change it to:

Class<FileListener> listener = (Class)Class.forName("com.xxx.SomeClass");

Which results in a warning: Type safety: The expression of type Class needs unchecked conversion to conform to Class<FileListener>

So I change it to:

Class<FileListener> listener = (Class<FileListener>)Class.forName("com.xxx.SomeClass");

Which again results in warning: Type safety: The cast from Class<capture-of ?> to Class<FileListener> is actually checking against the erased type Class

Now, I realize I can block these warnings with @SuppressWarnings, but I think that is very bad code style, as it will block warnings for an entire method.

I realize that the last warning (checking against erased type) is there to tell me that you might get a ClassCastException during runtime (even though I'm using generics) because the generic information is removed after compilation -- but why is this worth mentioning?  I added a _cast_ to my code, so of course I can expect a ClassCastException if something goes wrong -- any cast will do this, whether or not it is generics related or not -- there's no point to explicitely mention this to me again.

The warning seems to me like giving a warning on this code (in JDK 1.4)

ArrayList list = (ArrayList)object;

And then telling me: "Well, you might get a ClassCastException there you know!".

Okay, now on to the actual problem.  I'd like to disable the last warning globally (checking against erased type), but I like to keep the first warning (unchecked conversion).  I want people to type the full generic cast in the code, as an extra reminder that what they're doing might cause problems, and as an indication that they really expect the casted object to adhere to their generic restrictions.  However I want the code to be warning free.  This is currently not possible because the option "Unchecked generic type operation" disables both warnings when you set it to ignore.

@SupressWarnings at the method level is not good enough.  It also disabled both warnings, and to be honest, disabling these for an entire method is too big a scope.

More information:
Comment 1 Markus Keller CLA 2007-01-11 07:37:58 EST
> I realize that the last warning (checking against erased type) is there to tell
> me that you might get a ClassCastException during runtime (even though I'm
> using generics) because the generic information is removed after compilation --
> but why is this worth mentioning?  I added a _cast_ to my code, so of course I
> can expect a ClassCastException if something goes wrong -- any cast will do
> this, whether or not it is generics related or not -- there's no point to
> explicitely mention this to me again.

The problem is that a cast to a parameterized type only checks the erasure. It does *not* fail with a ClassCastException if the type argument is not correct. Instead, this cast may cause heap pollution, which can later cause ClassCastExceptions at locations where no cast is present in source. See e.g. http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#What%20is%20heap%20pollution?
Comment 2 John Hendrikx CLA 2007-01-11 07:55:52 EST
> The problem is that a cast to a parameterized type only checks the erasure. It
> does *not* fail with a ClassCastException if the type argument is not correct.
> Instead, this cast may cause heap pollution, which can later cause
> ClassCastExceptions at locations where no cast is present in source. See e.g.
> http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#What%20is%20heap%20pollution?
> 

Yes, I know that it won't actualy check if it conforms and then fail at that exact spot in my program.  It will fail at a later point.  I didn't know this was referred to as heap polution.  The basic problem remains the same for me though, although perhaps a different solution is in order.  Before Java 5, I could write all my code warning free with practically all warnings active.  With Java 5, I can't, unless I use kludges like @SupressWarnings.

The problem seems to be a fundamental one.  At some point everyone is running into this problem.  I wouldn't mind using Class<?> instead, but the problem then just moves itself further down into the code, eventually, I have to cast somewhere.  I'm a big fan of using generics everywhere, and I cringe at older classes without generic support, but it seems the problem may be hard to solve without runtime information about the generics.
Comment 3 Markus Keller CLA 2007-01-11 09:17:15 EST
IMO, the "Unchecked generic type operation" option should directly map to javac's -Xlint option.

However, I would not be against adding a separate token to suppress only unsafe cast warnings, e.g. @SuppressWarnings("unchecked cast").