Converting java.util.Properties to HashMap

Properties properties = new Properties(); Map<String, String> map = new HashMap<String, String>(properties);// why wrong? 

java.util.Properties is a implementation of java.util.Map, And java.util.HashMap's constructor receives a Map type param. So, why must it be converted explicitly?

14 Answers

This is because Properties extends Hashtable<Object, Object> (which, in turn, implements Map<Object, Object>). You attempt to feed that into a Map<String, String>. It is therefore incompatible.

You need to feed string properties one by one into your map...

For instance:

for (final String name: properties.stringPropertyNames()) map.put(name, properties.getProperty(name)); 

The efficient way to do that is just to cast to a generic Map as follows:

Properties props = new Properties(); Map<String, String> map = (Map)props; 

This will convert a Map<Object, Object> to a raw Map, which is "ok" for the compiler (only warning). Once we have a raw Map it will cast to Map<String, String> which it also will be "ok" (another warning). You can ignore them with annotation @SuppressWarnings({ "unchecked", "rawtypes" })

This will work because in the JVM the object doesn't really have a generic type. Generic types are just a trick that verifies things at compile time.

If some key or value is not a String it will produce a ClassCastException error. With current Properties implementation this is very unlikely to happen, as long as you don't use the mutable call methods from the super Hashtable<Object,Object> of Properties.

So, if don't do nasty things with your Properties instance this is the way to go.

You could use Google Guava's:

com.google.common.collect.Maps.fromProperties(Properties)

The Java 8 way:

properties.entrySet().stream().collect( Collectors.toMap( e -> e.getKey().toString(), e -> e.getValue().toString() ) ); 

How about this?

 Map properties = new Properties(); Map<String, String> map = new HashMap<String, String>(properties); 

Will cause a warning, but works without iterations.

Properties implements Map<Object, Object> - not Map<String, String>.

You're trying to call this constructor:

public HashMap(Map<? extends K,? extends V> m) 

... with K and V both as String.

But Map<Object, Object> isn't a Map<? extends String, ? extends String>... it can contain non-string keys and values.

This would work:

Map<Object, Object> map = new HashMap<Object, Object>(); 

... but it wouldn't be as useful to you.

Fundamentally, Properties should never have been made a subclass of HashTable... that's the problem. Since v1, it's always been able to store non-String keys and values, despite that being against the intention. If composition had been used instead, the API could have only worked with string keys/values, and all would have been well.

You may want something like this:

Map<String, String> map = new HashMap<String, String>(); for (String key : properties.stringPropertyNames()) { map.put(key, properties.getProperty(key)); } 

I would use following Guava API: com.google.common.collect.Maps#fromProperties

Properties properties = new Properties(); Map<String, String> map = Maps.fromProperties(properties); 

If you know that your Properties object only contains <String, String> entries, you can resort to a raw type:

Properties properties = new Properties(); Map<String, String> map = new HashMap<String, String>((Map) properties); 

The problem is that Properties implements Map<Object, Object>, whereas the HashMap constructor expects a Map<? extends String, ? extends String>.

This answer explains this (quite counter-intuitive) decision. In short: before Java 5, Properties implemented Map (as there were no generics back then). This meant that you could put any Object in a Properties object. This is still in the documenation:

Because Properties inherits from Hashtable, the put and putAll methods can be applied to a Properties object. Their use is strongly discouraged as they allow the caller to insert entries whose keys or values are not Strings. The setProperty method should be used instead.

To maintain compatibility with this, the designers had no other choice but to make it inherit Map<Object, Object> in Java 5. It's an unfortunate result of the strive for full backwards compatibility which makes new code unnecessarily convoluted.

If you only ever use string properties in your Properties object, you should be able to get away with an unchecked cast in your constructor:

Map<String, String> map = new HashMap<String, String>( (Map<String, String>) properties); 

or without any copies:

Map<String, String> map = (Map<String, String>) properties; 

this is only because the constructor of HashMap requires an arg of Map generic type and Properties implements Map.

This will work, though with a warning

 Properties properties = new Properties(); Map<String, String> map = new HashMap(properties); 

You can use this:

Map<String, String> map = new HashMap<>(); props.forEach((key, value) -> map.put(key.toString(), value.toString())); 

First thing,

Properties class is based on Hashtable and not Hashmap. Properties class basically extends Hashtable

There is no such constructor in HashMap class which takes a properties object and return you a hashmap object. So what you are doing is NOT correct. You should be able to cast the object of properties to hashtable reference.

i use this:

for (Map.Entry<Object, Object> entry:properties.entrySet()) { map.put((String) entry.getKey(), (String) entry.getValue()); } 

When I see Spring framework source code,I find this way

Properties props = getPropertiesFromSomeWhere(); // change properties to map Map<String,String> map = new HashMap(props)