• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Mxolisi Veco
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@SuppressWarnings("unchecked")
 
Istvan Kovacs
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15452
42
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mxolisi Veco
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks.
Thats what I decided to do.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic