aspose file tools*
The moose likes Beginning Java and the fly likes How to cast an Object to a HashMap with out getting unchecked cast warning Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "How to cast an Object to a HashMap with out getting unchecked cast warning" Watch "How to cast an Object to a HashMap with out getting unchecked cast warning" New topic
Author

How to cast an Object to a HashMap with out getting unchecked cast warning

Mxolisi Veco
Ranch Hand

Joined: Jan 14, 2010
Posts: 59
Good day.

I have the following code



When I compile this I get



What can I add to the statement such that I will not get the uncheck warning ?
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

@SuppressWarnings("unchecked")
Istvan Kovacs
Ranch Hand

Joined: May 06, 2010
Posts: 100
Mxolisi Veco wrote:
What can I add to the statement such that I will not get the uncheck warning ?


There's no clean solution, you have to suppress the warning, as David has said.
The reason is that at runtime, you have no information on the type parameters, so no magic will save you. You could improve this somewhat by turning y into HashMap<Integer, String> though, so you'll be type-safe at least from that point on (if y really is that type - it is, in your case, but if it's something you've restored from serialised form, or got from some other piece of code you have no control over, and the Object points to a HashMap where the key and the value are not Integer and String, you'll run into ClassCastExceptions, or, even worse, hard to find bugs - Map.get, containsKey, containsValue take Object as parameter so no cast/typecheck will be performed even at runtime, get will just return null, contains* false).
Mxolisi Veco
Ranch Hand

Joined: Jan 14, 2010
Posts: 59
I will use @SuppressWarnings("unchecked").

I tried but the warning were still there. So suppressing the warning does the job.

The chance of getting a ClassCastException is zero because I build the part that returns an Object that contains a HashMap<Integer,String>. The problem is I can not return the HashMap<Integer,String> I can return Object though. So I put the HashMap<Integer,String> in the object as a result.

The problem is solved now thanks.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Why can't you return the actual object? Seems like you're working around the type "safety" that Java gives you.
Mxolisi Veco
Ranch Hand

Joined: Jan 14, 2010
Posts: 59
1. I read the object from a remote server, so java.‚Äčio.‚ÄčObjectInputStream readObject() only returns an Object
2. I need something that can carry a HashMap in the event of a succesful search or an exception in the event of a failure.
The only thing that I know tha can carry any of these is an Object.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

If you're always getting either an exception or the HashMap, why not just wrap the call and either return an object or throw an app-specific exception?
Mxolisi Veco
Ranch Hand

Joined: Jan 14, 2010
Posts: 59
I am not sure if i understand what you mean by
wrap the call
.

This is what I do currently

From what I understand, I will still get the results from the server as an Object and I will be forced to cast the results which will generate a warning. So suppressing the warning seems to be the only way to work around this without complicating the source code.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

So the thing you're returning doesn't need to hold *either* a HashMap *or* an exception, which is what you said originally:
2. I need something that can carry a HashMap in the event of a succesful search or an exception in the event of a failure.

Mxolisi Veco
Ranch Hand

Joined: Jan 14, 2010
Posts: 59
It does need to hold an Exception or a HashMap.
What is it that I wrote that makes you think it does not?

The server is running on a different machine, if a throw the exception on the server side, then the client will never know that something went wrong. So I return the Exception or the HashMap to the calling client. Then the client checks the results that they contain the HashMap. If the results are not a HashMap, then they are an exception.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Mxolisi Veco wrote:What is it that I wrote that makes you think it does not?

Because you said:

2. Check that the result are of type HashMap
    if results are of type HashMap
        cast the results to a HashMap
    otherwise
        throw an exception.

Throwing an exception is not the same as returning an exception. If you're *returning* an exception, you're correct--but that would defeat the purpose of both exceptions, and type safety.

My original suggestion still stands: either return the HashMap, or throw an exception. Keep the signature as a HashMap and keep the code that calls the method substantially cleaner.
Mxolisi Veco
Ranch Hand

Joined: Jan 14, 2010
Posts: 59
When I read the results from the server, you read it as an object, so I need to cast those results to HashMap. The casting is the problem.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14347
    
  22

There is no way to get out of this, the only thing you can do to get rid of the warning is by using the @SuppressWarnings annotation.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Mxolisi Veco
Ranch Hand

Joined: Jan 14, 2010
Posts: 59
Thanks.
Thats what I decided to do.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to cast an Object to a HashMap with out getting unchecked cast warning