# Map<String, HashSet<String>> Umwandeln in Map<String, ArrayList<String>>



## noetig (16. Sep 2009)

Ich habe eine eine Map im Type String und HashSet (damit ich bei den Übersetzungen keine Duplikate erhalte.)

Das sieht dann so aus...
{fun={spaß},{freude}}


Jetzt möchte ich aber gerne dieses Map 
	
	
	
	





```
Map<String, HashSet<String>>
```
 umwandeln in ein 
	
	
	
	





```
Map<String, ArrayList<String>>
```
 da ich dies als Rückgabewert haben muss.

Versuche wie Map<String, ArrayList<String>> neueMap = alteMap; schlagen fehl.

Ich würde auserdem wissen wie ich direkt nur auf das HashSet zugreifen kann ohne die ganze Map zu verwenden.

Hat jemand den rettenden Tipp?


----------



## Landei (16. Sep 2009)

Am Umkopieren kommst du nicht vorbei:
(aus'm Kopp und ungetestet)

```
Map<String, HashSet<String>> hsMap = ...
Map<String, ArrayList<String>> alMap = new HashMap<String, ArrayList<String>>(); 
for(Map.Entry<String, HashSet<String>> entry : hsMap.entrySet()) {
 alMap.put(entry.getKey(), new ArrayList<String>(entry.getValue()));
}
return alMap;
```


----------



## Spacerat (17. Sep 2009)

Hier arbeitet man doch mit Collections... Warum dieses "for"-Konstrukt?
	
	
	
	





```
Map<String, Set<String>> from = ...
Map<String, List<String>> to = new HashMap<String, List<String>>();
Iterator<Map.Entry<String, Set<String>> i = from.entrySet.iterator();
Map.Entry<String, Set<String> entry;
while(i.hasNext()) {
  entry = i.next();
  to.put(entry.getKey(), new ArrayList<String>>(entry.getValue()));
}
```


----------



## Beni (17. Sep 2009)

Spacerat hat gesagt.:


> Hier arbeitet man doch mit Collections... Warum dieses "for"-Konstrukt?



Vermutlich weil es einfacher ist und weniger Code geschrieben werden muss?   (Mit dem for braucht man den Iterator nicht explizit aufzuschreiben).


----------



## Verjigorm (17. Sep 2009)

Wieso iterator benutzen wenns auch ohne geht?
Ich versuch den immer zu vermeiden


----------



## SlaterB (17. Sep 2009)

wie war das nicht letztens in der Umfrage, keySet oder entrySet?
ich finde das mit den Keys schöner, Performance ist doch nebensächlich

```
Map<String, HashSet<String>> hsMap = ...
Map<String, ArrayList<String>> alMap = new HashMap<String, ArrayList<String>>(); 
for(String key : hsMap.keySet()) {
 alMap.put(key, new ArrayList<String>(hsMap.get(key)));
}
return alMap;
```


----------



## Spacerat (17. Sep 2009)

Öhm... Ok... Ich nahm an, dass dieses "for" nur mit Arrays funktioniert und nicht mit Collections.


----------



## Verjigorm (17. Sep 2009)

Spacerat hat gesagt.:


> Öhm... Ok... Ich nahm an, dass dieses "for" nur mit Arrays funktioniert und nicht mit Collections.



Das ist doch grade das "neue", tolle daran!


----------



## bygones (17. Sep 2009)

Spacerat hat gesagt.:


> Öhm... Ok... Ich nahm an, dass dieses "for" nur mit Arrays funktioniert und nicht mit Collections.



sie funktionieren mit allen Iterables (lassen wir mal aussenvor dass Arrays wieder mal was anderes sind ;-) )


----------



## Spacerat (17. Sep 2009)

All Right... Hab's inzwischen nach gelesen. Ganz beiläufig auch noch erfahren, dass Arrays in diesem For-Each-Konstrukt vermieden werden sollten. Der Grund: Arrays werden in eine List geboxt, was (zusätzlich zu anderen nachteiligen Nebeneffekten) recht unperformant ist. Also: nicht für Unklug...


----------



## noetig (17. Sep 2009)

also ich sehe...viele Wege führen nach Rom, für mich zählt jetzt mal, Hauptsache es läuft  Ich schau mir aber die anderen Lösungen noch mal an.

Ich hab da aber immer noch ein anderes Problem, wie kann ich denn nur auf einen Teil (unten rot) des Maps hsMap zugreifen?

Map<String, HashSet<String>> hsMap = ...


----------



## bygones (17. Sep 2009)

du brauchst den key dafür - also den string unter dem du ds gespeichert hast ueber get(String key)


----------



## Landei (17. Sep 2009)

Spacerat hat gesagt.:


> Hier arbeitet man doch mit Collections... Warum dieses "for"-Konstrukt?
> 
> 
> 
> ...



Das Hauptproblem, was ich mit diesem Stil habe, ist nicht die Zeile mehr: Der Iterator ist außerhalb der Schleife sichtbar, und das ist schlecht. Ich habe viel mit älterem Code zu tun, der genau so geschreiben ist (außer dass die Iteratoren nicht generisch sind, was das Problem noch vergrößert), und ich habe in einigen Fällen Bugs gefunden, die auf der versehentlichen "Wiederverwendung" des Iterators in der nächsten Schleife beruhten. Da braucht man ein Mikroskop und viel Geduld, um endlich irgendwann darauf zu kommen, dass ein iter2 eigentlich ein iter3 sein sollte oder so...

Es gibt auch noch die Variante, wo der Iterator in einer for-Schleife erzeugt und "getaktet" wird - das ist schon ein wenig besser.


----------



## Spacerat (17. Sep 2009)

Landei hat gesagt.:


> Das Hauptproblem, was ich mit diesem Stil habe, ist nicht die Zeile mehr: Der Iterator ist außerhalb der Schleife sichtbar, und das ist schlecht. Ich habe viel mit älterem Code zu tun, der genau so geschreiben ist (außer dass die Iteratoren nicht generisch sind, was das Problem noch vergrößert), und ich habe in einigen Fällen Bugs gefunden, die auf der versehentlichen "Wiederverwendung" des Iterators in der nächsten Schleife beruhten. Da braucht man ein Mikroskop und viel Geduld, um endlich irgendwann darauf zu kommen, dass ein iter2 eigentlich ein iter3 sein sollte oder so...
> 
> Es gibt auch noch die Variante, wo der Iterator in einer for-Schleife erzeugt und "getaktet" wird - das ist schon ein wenig besser.


Waaaahhhhh... Jajaja... zerfleischt mich ruhig... Dann eben kein Iterator... und jede Menge Tipparbeit für mich. OMG.


----------



## maki (17. Sep 2009)

Hat nix mit zerfleischen zu tun Spacerat 

Leider werden schleifen oft per C&P "wiederverwendet", je mehr Abhängigkeiten zum Kontext der Schleife existieren, umso mehr Möglichkeiten gibt es Fehler einzuschleusen. 
Eine for Schleife hat den Vorteil, das oft (nicht immer) alle Abhängigkeiten der Schleife selbst im Schleifenkopf deklariert und initialisiert sind.


----------

