Möchte "Unchecked cast"-Warnung loswerden

Hey,

ich habe momentan eine nicht loszuwerdende Warnung in einem meiner Unit-Tests.

Und zwar caste ich von Object zu Consumer<String>, was an dieser Stelle auch Sinn ergibt, da ich den zweiten Parameter eines aufzurufenden Lambda-Ausdrucks manipulieren möchte, sobald die entsprechende Methode meines gemockten Objekts aufgerufen wird.

Hier die entsprechende Stelle (Stelle mit Warnung in Zeile 3):

when(givenPage.executeJs(givenJsExpression)).thenReturn(givenPendingJsInvocation);
doAnswer(answer -> {
    val consumer = (Consumer<String>) answer.getArgument(1);
    consumer.accept(givenJwt);
    return null;
}).when(givenPendingJsInvocation).then(eq(String.class), ArgumentMatchers.any());

Und das ist der vom Unit-Test betroffende Teil der Methode im Service:

page.executeJs("return localStorage.getItem('" + LOCAL_STORAGE_KEY + "');").then(
    String.class, result -> session.setAttribute(VAADIN_SESSION_KEY, result)
);

Eigentlich sollte der Cast durch den ersten Parameter des Lambda-Ausdrucks ohne Bedenken sein, weil dieser spezifiziert, dass der Rückgabewert vom Typ "String" ist. Genauso haben die Jungs und Mädels vom Vaadin-Team auch kein besseres Vorgehen vorgeschlagen.

Ansonsten läuft dieser Test (und alle weiteren) sorgenfrei durch und meine CI auf GitLab hat nichts zu beanstanden.

Ich kann mir diesen Umstand, JavaScript aufzurufen, nicht sparen. Vaadin hat bisher keine Funktionalität, den LocalStorage ohne eigenen Wrapper anzusprechen. Ich brauche den LocalStorage, weil ich diesen für optionale externe Frontends (ein optionales Angular-Frontend von mir) ebenfalls als Session-Storage verwende und somit einen Speicherort an gleicher Stelle für alle habe.

Ich hoffe, das klingt nicht komisch, aber ich versuche Quellcode frei von Warnungen zu halten.

Hat jemand eine Idee, ob es einen sauberen Ansatz gibt oder sollte ich es einfach so hinnehmen? ...

Mechanics

@SuppressWarnings?

Oder suchst du eine Möglichkeit, das ohne SuppressWarnings zu machen?

@Mechanics sagte in Möchte "Unchecked cast"-Warnung loswerden:

Oder suchst du eine Möglichkeit, das ohne SuppressWarnings zu machen?

Danke Dir, tatsächlich lag/liegt meine Hoffnung beim Vermeiden einer Warnunterdrückung.

Naja, vielleicht ist es wieder einer meiner Schwachsinnsutopievorhaben und ich unterdrücke die Warnung einfach.

Mechanics

Ich wüsste jetzt grad nicht, wie man das generell vermeiden könnte. Wenn man instanceof Consumer<String> machen könnte, würde die Warnung nicht kommen. Aber wegen dem behinderten Generics System in Java geht das nicht.

Was ist das answer und was sind die Argumente? Kann man da irgendwo die accept Methode verstecken oder was ähnliches machen? z.B. argument instanceof JwtAcceptor?

firefly

Jo, in java sind zur laufzeit die typen eines generics nicht mehr vorhanden.
Hab da zwei post auf stackoverflow gefunden die das gleiche Problem schildern (nur mit einem anderen Generic type)

https://stackoverflow.com/questions/509076/how-do-i-address-unchecked-cast-warnings/509115
https://stackoverflow.com/questions/262367/type-safety-unchecked-cast

@Mechanics sagte in Möchte "Unchecked cast"-Warnung loswerden:

Aber wegen dem behinderten Generics System in Java geht das nicht.

Genau DAS. Leider ist es nicht das einzig behinderte an Java und Lombok macht auch nicht alles wett.

Was ist das answer und was sind die Argumente?

Mit dem Parameter "answer" von "doAnswer" ermöglicht mir Mockito den Zugriff auf die Parameter der lokalen Invokation (hier der Lambda-Ausdruck), womit ich dann den zweiten Parameter manipulieren kann.

Kann man da irgendwo die accept Methode verstecken oder was ähnliches machen? z.B. argument instanceof JwtAcceptor?

Nee, leider nicht und Mockito geht dort ohnehin (ohne Cast) von einem Object aus. Man muss dazu auch sagen, dass die Implementierung von Vaadin an einigen Stellen auch einfach schei*e ist.

@firefly sagte in Möchte "Unchecked cast"-Warnung loswerden:

Hab da zwei post auf stackoverflow gefunden die das gleiche Problem schildern (nur mit einem anderen Generic type)

Habe es nun auch mit einer lokalen Warnunterdrückung geregelt, sonst bin ich 2022 noch nicht mit dem Schichtplaner fertig.