Converting java.util.Properties to HashMap<String,String>

Java

Java Problem Overview


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?

Java Solutions


Solution 1 - Java

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));

Solution 2 - Java

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.

Solution 3 - Java

Solution 4 - Java

How about this?

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

Will cause a warning, but works without iterations.

Solution 5 - Java

The Java 8 way:

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

Solution 6 - Java

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));
}

Solution 7 - Java

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

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

Solution 8 - Java

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);

Solution 9 - Java

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;

Solution 10 - Java

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);

Solution 11 - Java

You can use this:

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

props.forEach((key, value) -> map.put(key.toString(), value.toString()));

Solution 12 - Java

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.

Solution 13 - Java

i use this:

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

Solution 14 - Java

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)

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionTardis XuView Question on Stackoverflow
Solution 1 - JavafgeView Answer on Stackoverflow
Solution 2 - JavapadiloView Answer on Stackoverflow
Solution 3 - JavaAshwin JayaprakashView Answer on Stackoverflow
Solution 4 - JavaSeshadri SastryView Answer on Stackoverflow
Solution 5 - JavaBen McCannView Answer on Stackoverflow
Solution 6 - JavaJon SkeetView Answer on Stackoverflow
Solution 7 - Javavatsal mevadaView Answer on Stackoverflow
Solution 8 - JavaLukas EderView Answer on Stackoverflow
Solution 9 - JavaMattias BuelensView Answer on Stackoverflow
Solution 10 - JavaEvgeniy DorofeevView Answer on Stackoverflow
Solution 11 - JavaRaman SahasiView Answer on Stackoverflow
Solution 12 - JavaJuned AhsanView Answer on Stackoverflow
Solution 13 - JavaatomView Answer on Stackoverflow
Solution 14 - JavaQ10VikingView Answer on Stackoverflow