Discussion :

[tchize_]

Bonjour,

Je viens de faire le code suivant, pour parcourir un java.util.Properties avec une lambda et un forEach en gardant les String et sans devoir créer une nouvelle map :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
        Properties props = new Properties();
        ((Hashtable<String, String>) ((Hashtable<?,?>) props))
            .forEach((key,value) -> 
                earnedMonths.put(Period.parse(key),Period.parse(value))
                );

Quelqu'un aurait-il mieux ?

La Hashtable contient d'office des paires <String, String> mais quelqu'un de chez SUN/Oracle a décidé que ça implémenterait Map<Object,Object>...

Merci d'avance.

[thelvin]

Personnellement je ferais une variable temporaire de type Map<String, String> au lieu de juste mettre une parenthèse alambiquée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Properties props = new Properties();
@SuppressWarnings({ "unchecked", "rawtypes" }) // Properties only contain Strings!!!
Map<String, String> propStrings = (Map)props;
propStrings.forEach((key,value) -> 
  earnedMonths.put(Period.parse(key),Period.parse(value)));

J'aurais aussi pensé à juste faire des cast sur key et value, mais du coup la lambda est bien moins lisible :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Properties props = new Properties();
props.forEach((key,value) -> 
  earnedMonths.put(Period.parse((String)key),Period.parse((String)value)));

Fondamentalement, le problème est que la classe Properties obsolète n'a pas la fonctionnalité nécessaire pour écrire du code simple et clair. Ma solution personnelle serait autant que possible s'en passer ou la planquer derrière une méthode utilitaire qui la convertit en jolie Map<String, String>, et s'arranger pour le faire assez tôt pour que ce soit pas dans le code qui va la traiter.

[tchize_]

C'est effectivement un peu plus lisible

[bouye]

Et ça ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 properties.entrySet().stream()
                .map(entry -> (Map.Entry<String, String>) (Object) entry)
                .forEach(entry -> earnedMonths.put(Period.parse(entry.getKey()), Period.parse(entry.getValue())));

EDIT - correction de bourde : remplacement de values() par entrySet() et donc du coup double cast pour éviter une erreur de impossible de caster Map.Entry<Object, Object> en Map.Entry<String, String>

[tchize_]

j'ai l'impression avec ta solution de mettre plus de temps à comprendre ce que fait le code qu'avec la première de thelvin

[bouye]

Ah ?! Pourtant meme moi qui ait parfois du mal avec les streams, je la trouve plutôt claire et même pas du tout éloignée de la tienne du début en fait :
props.forEach(BiConsumer<Object, Object>) revient a faire props.entrySet().forEach(Consumer<Map.Entry<Object, Object>>).

La fonction map() sert a convertir un stream d'un certain type T en un stream d'un autre type R.
Ici, on passe donc d'un Stream<Map.Entry<Object, Object>> Stream<Map.Entry<String, String>>

Bon ceci dit je viens de me rendre compte que :
1) j'avais mis values() au lieu de entrySet() -> welcome le ClassCastException a l'execution.
2) j'avais pas teste un code qui donc ne fonctionnait pas.

Donc j'ai corrige le code mais ça demande de toute manière de mettre un second cast car on ne peut pas caster de Map.Entry<Object, Object> Map.Entry<String, String>. Il faut donc caster Map.Entry<Object, Object> Object Map.Entry<String, String> et donc c'est a nouveau pas beau.

[tchize_]

j'ai pas dit qu'elle était impossible à lire non plus. C'est juste qu'alors que le but est juste de parcourir les entrée, on retrouve un map dans la lambda, ce qui amène à un temps de pause pour ce dire "ha tiens, on convertis les données?"

j'ai opté au final pour la version avec le typecasting vers string sur la fin, qui reste la plus propre.


Mais pourquoi diable Properties n'implémente pas Map<String,String> b*** de zut