What is the proper way to resolve Eclipse warning "isn't parameterized"?

Question

I'm trying to clean up some warnings in some old Java code (in Eclipse), and I'm unsure what the proper thing to do is in this case. The block looks more or less like this:

Transferable content = getToolkit().getSystemClipboard().getContents( null );
java.util.List clipboardFileList = null;

if( content.isDataFlavorSupported( DataFlavor.javaFileListFlavor ) ) {
  try {
    clipboardFileList = (java.util.List)content.getTransferData(
      DataFlavor.javaFileListFlavor);
  }
  /* Do other crap, etc. */
}

The List generates a warning as it isn't parameterized, however, if I parameterize it with <File>, which I'm pretty sure is what it requires, it complains that it can't convert from Object to List<File>. I could merely suppress the unchecked warning for the function, but would prefer to avoid that if there is a "good" solution. Thoughts?

Answer 1

Try this

java.util.List<?>

Answer 2

The correct way to resolve the warning is to turn the raw list into a parameterized one (a List<File>) but that depends on how the list is getting created in the first place.

content.getTransferData(DataFlavor.javaFileListFlavor) should really be returning an object whose type is specific as possible - my guess is that it's just not implemented in a totally generic way, unfortunately.

Answer 3

I don't think you need to use <?>. This just works fine for me?

Object obj = null;
List<File> aa = (List<File>)obj;

Answer 4

I would recommend explicitly casting the result to List<File> and suppressing the warning. According to the documentation:

public static final DataFlavor javaFileListFlavor

To transfer a list of files to/from Java (and the underlying platform) a DataFlavor of this type/subtype and representation class of java.util.List is used. Each element of the list is required/guaranteed to be of type java.io.File.

In such a situation where the documentation clearly defines the data type, feel free to ignore the warnings, as per Item 24 of Joshua Bloch's Effective Java (page 116):

If you can't eliminate a warning, and you can prove that the code that provoked the warning is typesafe, then (and only then) suppress the warning with an @SuppressWarnings("unchecked") annotation.