Java Streams

[krgewb]

Wie kann ich das ohne Streams schreiben?

List<String> collect = m.keySet().stream()
.filter(c-> c.equals(clientWSInformation))
.map(ClientWSInformation::getWebSocketId)
.collect(Collectors.toList());

m ist vom Typ ConcurrentMap<ClientWSInformation, PlayerClient>

 

[mihe7]

So in der Richtung:

List<String> webSocketIds = new ArrayList<>();
for (ClientWSInformation info : m.keySet()) {
    if (info.equals(clientWSInformation)) {
        webSocketIds.add(info.getWebSocketId());
    }
}

EDIT: hatte den Filter vergessen...

Noch ein Nachtrag: im Code werden einige Annahmen getroffen, man bräuchte aber mehr Informationen, um das sicher zu sagen. Beispielsweise bin ich stillschweigend davon ausgegangen, dass das KeySet vom Typ ClientWSInformation ist. Das muss nicht der Fall sein, ebenso könnte getWebSocketId eine statische Methode sein, die einen Parameter erwartet.

 

[filter]

Schnell noch etwas Technisches ... Unter der Annahme, dass Map m bzw. m.keySet() auch null-Values enthält, wäre es sinnvoller, clientWSInformation.equals(info) zu schreiben. Zudem sollte bei der Deklaration ClientWSInformation info auch der generic type angeben werden, sofern vorhanden. Somit ergibt sich:

List<String> webSocketIds = new ArrayList<>();

for (ClientWSInformation<?> info : m.keySet()) {
    if (clientWSInformation.equals(info)) {
        webSocketIds.add(info.getWebSocketId());
    }
}

 

[mrBrown]

Unter der Annahme, dass Map m bzw. m.keySet() auch null-Values enthält, wäre es sinnvoller, clientWSInformation.equals(info) zu schreiben.

"sinnvoller" ist da sehr umstritten, gleichermaßen könnte man Argumentieren dass man falls null erlaubt ist dies auch explizit machen sollte oder andernfalls die andere Variante nutzen und die NPE provozieren sollte, damit es auffällt.

(Und Yoda-Conditions sind einfach generell schlechter Stil )

 

[KonradN]

Wenn man null als gültigen/möglichen Wert annimmt, dann wäre doch auch nicht das Umdrehen der Parameter sondern die Verwendung von Objects.equals angebracht, oder? Denn dann müsste man es ja auch für clientWSInformation in Betracht ziehen und man müsste dann konsequenter Weise auch null Werte ausfiltern können wollen.

Generell ist da aber immer die Frage, ob das ein gutes Design ist. Evtl. sollte man Optional<T> in Betracht ziehen.

Aber ganz wichtig: Dabei sind wir von der ursprünglichen Frage abgekommen:

Wie kann ich das ohne Streams schreiben?

Und bei der 1:1 Umsetzung ist der Filter nun einmal: c-> c.equals(clientWSInformation und damit genau der Code, der in #2 gepostet wurde.

 

[filter]

"sinnvoller" ist da sehr umstritten, gleichermaßen könnte man Argumentieren dass man falls null erlaubt ist dies auch explizit machen sollte oder andernfalls die andere Variante nutzen und die NPE provozieren sollte, damit es auffällt.

Nö, er hat nach einem semantischen Äquivalent gefragt, meiner Meinung nach.

 

[filter]

(Und Yoda-Conditions sind einfach generell schlechter Stil )

Ist performanter, btw.

 

[KonradN]

Ist performanter, btw.

Woher kommt diese Aussage?

Das wäre dann erst einmal eine Form der Optimierung und da gilt in Clean Code der Ansatz: Don't do it (yet).

Ist außerdem ein Mythos, denn wenn es irgendwas bezüglich Performance machen würde, dann würde der Compiler das für einen machen. Wenn man bedenkt, was für komplexe Optimierungen sowohl vom Java Compiler als auch vom JIT Compiler gemacht werden, dann ist klar, dass so eine Sache absolut kein Thema wäre.

Aber dazu kann man auch einfach mal im Netz schauen:
Yoda Conditions: To Yoda or Not to Yoda - Know the Code

Wenn ein Ausdruck auch zugleich eine Bedingung sein kann, dann sehe ich noch ein, dass man evtl. zu YODA greift, um versehentliche Zuweisungen zu vermeiden. Aber das ist in Java nur dann möglich, wenn wir bereits ein Wahrheitswert als Typ haben.

Daher denke ich, dass die Lesbarkeit im Vordergrund stehen sollte. Und wenn die null Werte eine Rolle spielen, dann ist - wie schon erwähnt - Objects.equals der in meinen Augen bevorzugte Weg.

 

[filter]

Ist außerdem ein Mythos, denn wenn es irgendwas bezüglich Performance machen würde, dann würde der Compiler das für einen machen. Wenn man bedenkt, was für komplexe Optimierungen sowohl vom Java Compiler als auch vom JIT Compiler gemacht werden, dann ist klar, dass so eine Sache absolut kein Thema wäre.

Glaube du irrst dich, weil der Compiler das nicht ohne Semantik-Änderung an der Stelle optimieren darf. Aber ist ja cool, dass du inzwischen auch Anti-Pattern kennst. Jetzt nur noch verstehen.

 

[KonradN]

Es wäre super, wenn Du irgendwelche Argumente hättest. Dann könntest Du evtl. überzeugen. Ein "Tobias ist der Meinung, dass ..." hat sehr wenig Gewicht und wird uns kaum überzeugen.

 

[mrBrown]

Nö, er hat nach einem semantischen Äquivalent gefragt, meiner Meinung nach.

Dann ist dein Vorschlag also schon falsch, da es semantisch was anderes ist?

Ist performanter, btw.

In welchen Fällen sollte es da aus welchen Gründen einen Unterschied geben?