Java generics

I have the below generics code

List<Object[]> resultset = queryObj.list();

for(Object[] aoirecord:resultset){

//logic to do with recordss
}

at the first line of this code , i.e., queryObj.list(); I get the warning

Type safety: The expression of type List needs unchecked conversion to conform to List<Object[]>

could any one please help on getting rid of this warning?

Priyanka Sumanam wrote:I have the below generics code

List<Object[]> resultset = queryObj.list();

for(Object[] aoirecord:resultset){

//logic to do with recordss
}

at the first line of this code , i.e., queryObj.list(); I get the warning

Type safety: The expression of type List needs unchecked conversion to conform to List<Object[]>

could any one please help on getting rid of this warning?

I hate these also, as I work to produce code that has no warnings, but I don't think we should do anything about this type of warning.

The problem is queryObject.list() is returning a List not List<Object[]>. The way to deal with it properly is to change the called method (IMHO) but there are still plenty of code in class libraries out there that don't implement generics.

I'm assuming queryObj is in a class library and not your code. If you wrote it, just declare the return type List<Object[]>.

Joe

Hi Joe,

Thanks for the reply.Yes...as you said queryObj is the instance of Hibernate Query classs.
I just don't want to add @suppresswarning to id.So, just thought of finding out if there is a better way of doing it.

Cheers
Priya

May be i can extend the Hibernates query class and overload the list() method to return List<Objec[]> and use it for special cases like this in the application.

But, is it worth doing it just for the sake of this warning?
are there any potential unforeseen problems if I leave it so?

Thanks in advance
Priya

Pirya,

I don't consider myself an expert in this so please take this as one man's opinion.

I don't see much of an advantage to deriving a class to get rid of this warning. You'll just be moving the warning to that class.

As I understand the risk, it is very low when the generic type is Object, since any class can be cast to it.

The problem is getting a runtime cast error rather than a compile time error.

For example if using generics
List<Float> a = new List<String>();
would give a compile error and must be fixed before the program ran while
List<Float> a = new List();
gives you the unchecked conversion and something like
List<Float> a = getList();
could give you a run time error if getList returned a List that contained Strings, but not if it returned something that could be cast to Float.

I end up leaving the warning and hoping they decide to use generic declarations in the next release of the library.

Joe

Joe,

Thanks for the explanation.I totally agree with what you said.It would be waste of effort to do so.

Cheers
Priya

Joe Areeda wrote:
The problem is queryObject.list() is returning a List not List<Object[]>. The way to deal with it properly is to change the called method (IMHO) but there are still plenty of code in class libraries out there that don't implement generics.

I don't know, but probably that API was written before generics were introduced?

Jaikiran Pai wrote:
I don't know, but probably that API was written before generics were introduced?

That's what I believe.

You could write a utility method:
public static <T> List<T> asList(Object object, Class<T> cls, boolean checkElements) { if (o == null) { return null; } if (o instanceof List<?>) { List<?> list = (List<?>)o; // no warning if (checkElements) { for (Object element: list) { if (element != null && !cls.isInstance(element)) { throw new ClassCastException(element.getClass().getName() + " cannot be cast to " + cls.getName()); } } } @SupressWarnings("unchecked") List<T> result = (List<T>)list; // localize the suppression to one line return result; } throw new ClassCastException(o.getClass().getName() + " cannot be cast to " + List.class.getName()); }This is not 100% safe though, as the following example will show:
List<String> stringList = new ArrayList<String>(); List<Integer> intList = asList(stringList, Integer.class, true); // succeeds because there are no elements stringList.add("Hello"); intList.add(1); // both now have one String and one Integer

Rob,

I don't see the purpose of the Utility method. Perhaps it's to isolate potential runtime ClassCastException to the List assignment rather than the element of the List assignment. But it still needs to suppress the warning. Thanks for the example of how to suppress it for one line only. Also it is still susceptible to runtime errors.

In my mind the advantage of generics is stronger typing which allows the compiler catch potential runtime casting problems.

Libraries written before generics (or at least to be compatible with versions of Java before generics) haven't caused reliability problems for me.

Joe

Unfortunately, sometimes you just have to suppress warnings, because the generic type is no longer available at runtime. If it were a cast to List<Integer> would fail for a List<String>. But you probably suppress warnings quite a bit already, you just don't know it because the suppression occurs in other APIs. For example, the source code of Class.cast:
public T cast(Object obj) { if (obj != null && !isInstance(obj)) throw new ClassCastException(); return (T) obj; }OK, granted, there is no suppressing there, but there is line that would cause a warning if you'd compile this yourself. But because this code is not in your own project, this warning is still suppressed for your project.

Rob Spoor wrote:Unfortunately, sometimes you just have to suppress warnings, because the generic type is no longer available at runtime. If it were a cast to List<Integer> would fail for a List<String>. But you probably suppress warnings quite a bit already, you just don't know it because the suppression occurs in other APIs.

Oh I agree.

The syntax to suppress warnings for one line only will be a big help.

Sometimes, like this case where we use code from previous versions of Java, warnings are unavoidable. The best we can do is move them someplace else.

Sometimes writing code to remove warnings does not make the code safer or easier to understand.

A warning is not an error. To me it means that I should review the code in question and ask myself if there a better way to do it. With my feeble brain the answer is often I can't think of a better way.

I wouldn't underrate your brain; often there simply is no better way. Which comes to another good practice - document why suppressing warnings shouldn't lead to problems. In this case you could document (with a comment) saying that the documentation guarantees each element is an Object[] or something similar. The Class.cast documentation would say that the cls.isInstance check ensured that the cast is safe.