Win a copy of Head First Android this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

Want to avoid warning when I "cast" Properties to Map

 
Ranch Hand
Posts: 538
Hibernate Eclipse IDE Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I would like to avoid a warning when I "cast" Properties to Map, but I couldn't achieve it so far.

Example:
Properties props = new Properties();
Map<String, String> map = new HashMap<String, String>((Map) props); << Here is the warning, on ((Map) props)

It works in practice, I just would like to get rid of the warning if it is possible.

Best regards.
 
Sheriff
Posts: 3036
12
Mac IntelliJ IDE Python VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In theory, you could add an annotation to suppress the warning:



I think I'd be more comfortable writing my own loop to retrieve the properties and add them to the HashMap.
 
Eric Lemaitre
Ranch Hand
Posts: 538
Hibernate Eclipse IDE Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Greg Charles wrote:In theory, you could add an annotation to suppress the warning: @SuppressWarnings({ "rawtypes", "unchecked" })



Hi Greg,

Yes, I know the workaround and it works, but I really would like to know whether there is something which would allow to eliminate warning from this "cast" without having to do the whole loop to populate the Map.

Not sure at all it is possible, apart the @SuppressWarning annotation trick to hide it under the rug...

Best regards.
 
Rancher
Posts: 4686
7
Mac OS X VI Editor Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Eric Lemaitre wrote:like to know whether there is something which would allow to eliminate warning from this "cast" without having to do the whole loop to populate the Map.



Its actually bad form to do what you are trying to do. Its an accident that a Properties is a Hashtable, which happens to be implemented as a HashMap. The contract for Properties is that its a Hashtable, and the Hashtable is in turn a Map, but there is no contract that its a HashMap. This is a side effect and should not be relied upon as it might change in a future Java.

In practice, I think it will never change, but if you read the Javadocs from the JDK, there is no mention that a Properties is really a HashMap. And the Hashtable is synchronized, so unless you want that, you will have to move the K,V pairs to the proper Map.

I'm pretty sure that if you use Google's wonderful open source Guava library, then you can do something like:




If the props is empty like your trivial example, of course, then you don't need to do anything other than use the proper constructor.
 
Master Rancher
Posts: 4060
56
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Pat Farrell wrote:The contract for Properties is that its a Hashtable, and the Hashtable is in turn a Map, but there is no contract that its a HashMap.


True - but nothing Eric is doing here requires that it be a HashMap. Or a Hashtable, for that matter. He requires it to be a Map, which is fine. The real problem comes when he tries to cast it as a Map<String, String>. And it simply isn't one. Even though it should have been one. Sun made it a Map<Object, Object> instead, to avoid backwards compatibility issues.

Eric: no, there's really no workaround. You're dealing with a design defect in Properties, and there's no shortcut. Sorry.
 
Pat Farrell
Rancher
Posts: 4686
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike Simmons wrote: Sun made it a Map<Object, Object> instead, to avoid backwards compatibility issues.



IMHO, Sun did way too many of these "make it a kludge rather than breaking backwards compatibility" decisions. A classic example is the mess that they made of generics in Java 5.
 
Mike Simmons
Master Rancher
Posts: 4060
56
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And this is a particularly stupid example, because they're only helping people who decided to put something other than a String into their Properties object. Such people should be punished, not catered to. But that's the Java we live with.
 
Marshal
Posts: 74367
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And why do you want to cast it anyway? That is an upcast, which is usually unnecessary.
 
Mike Simmons
Master Rancher
Posts: 4060
56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ummm... to fix Sun's mistake? It should be a Map<String,String>, and using methods like entrySet() and keySet() requires extra casts because Sun made it a Map<Object,Object>. We should abandon Properties entirely, except its ability to read a standard prop file is something actually useful. So instead, we need a quick way to read a prop file and translate it to a Map<String,String>.
reply
    Bookmark Topic Watch Topic
  • New Topic