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

[Eric Lemaitre]

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.

[Greg Charles]

In theory, you could add an annotation to suppress the warning:

Properties props = new Properties(); 
@SuppressWarnings({ "rawtypes", "unchecked" })
Map<String, String> map = new HashMap<String, String>((Map) props);

I think I'd be more comfortable writing my own loop to retrieve the properties and add them to the HashMap.

[Eric Lemaitre]

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.

[Pat Farrell]

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:

Properties props = new Properties(); 
// prop.add, etc. to have real values in it.
Map<String, String> map = Maps.newHashMap(props);

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.

[Mike Simmons]

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]

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]

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.

[Campbell Ritchie]

And why do you want to cast it anyway? That is an upcast, which is usually unnecessary.

[Mike Simmons]

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>.