Compiler-Warnungen

[Oneixee5]

Mit @SuppressWarnings kann man in bestimmten Situationen Compiler-Warnungen unterdrücken. Gibt es auch eine Variante der Annotation, bei welcher man einen Grund angeben kann. Konkret möchte ich, dass die Verwendung von @SuppressWarnings("unused") begründet wird.

 

[Robert Zenz]

Keine die mir bekannt ist. Du kannst auch nicht SuppressWarnings erweitern, weil das mit @interfaces nicht geht.

Ich weiß gerade auch nicht ob du deine eigene Annotation schreiben kannst welche den gleichen Effekt hat, weil das wir ja in dem Fall nicht durch den Annotation-Processor gesteuert. Aber ich bilde mir ein es gaebe die Moeglichkeit in einem Annotation-Processor den Quellcode oder den AST zu veraendern, aber ich finde das Projekt welches ich dazu gesehen habe gerade nicht. Also was du machen koenntest ist die Sachen mit deiner eigenen Annotation versehen und dann im Processor die Sache umbauen so das eine SuppressWarnings an der Stelle steht.

Daneben gibt es halt nur die ueblichen Umgehungen wenn es rein umd as dokumentieren geht, Kommentar dazu schreiben, eine eigene Annotation dazu packen, oder als zusaetzliche "warning" in der Annotation aufnehmen:

@SuppressWarnings(value = { "unused", "reason:Weil es Seiteneffekte hat." })

Aber letzteres liefert eventuell auch wieder eigene Warnungen.

 

[LimDul]

Nope, gibt es nicht. Du bist zwingend auf die Annotation angewiesen um die Warnungen abzuschalten.

Was du machen kannst:

Per Vereinbarung
Es irgendwo als Bedingung festhalten, dass der Entwickler es dokumentieren muss, wenn er es verwendet und im Code-Review soll drauf geachtet werden.

Pro:
* Minimalster Aufwand
* Bei einem guten Entwicklerteam sieht das auch jeder ein
Contra:
* Es wird trotzdem vergessen

Automatisch prüfen
Hier würde mir folgende Idee einfallen:
* Eine eigene Annotation definieren (SuppressWarningsDocumentation)
* Je nach eingesetzten Tools prüfen, wie man dem eine Regel beibringt, dass eine SuppressWarning-Annotation immer von einer SuppressWarningsDocumentation Annotation begleitet werden muss.

Problem ist, dass SuppressWarnings Rentention.SOURCE hat, damit für Bytecode Analysetools wie ArchUnit nicht zur Verfügung steht, sprich es bleibt nur sowas übrig wie Checkstyle oder Spotbugs. Aber da kann man mit Sicherheit sowas ergänzen. Wie genau weiß ich nicht

Pro:
* Automatische Checks
Contra:
* Initialer Aufwand
* Setzt voraus, dass man ein derartiges Tools nutzt

Edit:

Die Idee von @Robert Zenz finde ich auch charmant, da evtl. mit eigenem Annotation Processor ran zu gehen. Wobei man da sicherstellen muss, dass ein Entwickler immer die eigene Annotation verwendet und nie die originale. Sprich das müsste zwei-stufig sein, erst prüfen ob ein SuppressWarnings da ist, wenn ja => Build fail. Wenn nein, dann die eigene Annotation durch SuppressWarnings ersetzen

 

[Robert Zenz]

Ja, das sollte gehen. Lombok macht genau so etwas wenn ich das gerade richtig verstanden habe. Also dein Annotation-Processor veraendert einfach den AST bevor der Compiler ihn zu sehen bekommt, da muesste auch das hinzufuegen und ersetzen von Annotationen dazu gehoeren.

 

[Neumi5694]

Findbugs bietet hier so was:
@SuppressFBWarnings(value = "RV_RETURN_VALUE_IGNORED_INFERRED", justification = "passt scho")

Das verhindert aber keine Standardwarnungen, nur eben die von Findbugs/Spotbugs.

 

[Oneixee5]

Findbugs bietet hier so was:
@SuppressFBWarnings(value = "RV_RETURN_VALUE_IGNORED_INFERRED", justification = "passt scho")

Das verhindert aber keine Standardwarnungen, nur eben die von Findbugs/Spotbugs.

Findbugs setzen wir nicht, wir verwenden Sonarlint. Das hätte ich evtl. erwähnen können. Trotzdem danke!

 

[Oneixee5]

Erst mal danke für die Antworten. Die Möglichleit "den AST zu veraendern" ich muss mir das erst mal bei Gelegenheit anschauen. So etwas habe ich noch nicht gemacht.

Bei einem guten Entwicklerteam sieht das auch jeder ein

Die Entwickler sind eher nicht das Problem, es geht eher darum schneller zu Überblicken warum so gehandelt wurde und ob der Grund evtl. hinfällig sein könnte. Ich möchte auch nicht übermäßig mit Mails zu Warnungen aus dem Build-System nerven. Der Gedanke muss wohl noch etwas reifen.

 

[LimDul]

Erst mal danke für die Antworten. Die Möglichleit "den AST zu veraendern" ich muss mir das erst mal bei Gelegenheit anschauen. So etwas habe ich noch nicht gemacht.

Die Entwickler sind eher nicht das Problem, es geht eher darum schneller zu Überblicken warum so gehandelt wurde und ob der Grund evtl. hinfällig sein könnte. Ich möchte auch nicht übermäßig mit Mails zu Warnungen aus dem Build-System nerven. Der Gedanke muss wohl noch etwas reifen.

Klar, aber es gibt auch Fälle wo man Entwickler im Team hat, die sowas nicht einsehen und dann kommt man mit freiwilligen Agreements nicht weiter und muss es technisch forcieren.

Aber halt auch bei guten Entwicklern wird es passieren, dass es vergessen wird, wenn man es nicht technisch forciert. Ich bin als Entwickler immer froh über alles, wo mir Tools (Jenkins, Checktyle, JUnit etc.) Arbeit abnehmen und mich auf Dinge hinweisen. Dann kann ich mich auf die wichtigen Sachen (Architektur etc.) konzentrieren und muss nicht immer die ganze Zeit an sämtlichen Kleinscheiss denken

 

[Oneixee5]

Funktioniert wunderbar ...

    @SuppressWarnings("unused")
    @SuppressWarningsDocumentation("suppress warnings documentation")

In die IDE muss man es zwar etwas umständlich einbinden damit diese auch die Annotation anwendet, der Focus liegt aber bei Maven und Build-Server

.../src$ javac -cp /.../annotations/bin -d ../bin ./*.java
./Main.java:17: error: @SuppressWarnings must be applied with @SuppressWarningsDocumentation
        public static void main(final String[] args) {
                           ^
1 error

 

[mrBrown]

In die IDE muss man es zwar etwas umständlich einbinden damit diese auch die Annotation anwendet

Wenn das in Maven als Annotation Processor eingebunden ist, sollte das doch auch in den meisten IDEs automatisch gehen?

 

[Robert Zenz]

Wenn das in Maven als Annotation Processor eingebunden ist, sollte das doch auch in den meisten IDEs automatisch gehen?

Zumindest fuer Eclipse trifft das nicht zu, weil Eclipse eine eigene Compiler-Infrastruktur hat. Ich denke das trifft auf die meisten IDEs zu, damit stellt sich die Frage ob diese Eigenschaften aus dem Maven Build-File uebernommen werden, und ich denke nicht dass das der Fall ist.

 

[mrBrown]

Zumindest fuer Eclipse trifft das nicht zu, weil Eclipse eine eigene Compiler-Infrastruktur hat. Ich denke das trifft auf die meisten IDEs zu, damit stellt sich die Frage ob diese Eigenschaften aus dem Maven Build-File uebernommen werden, und ich denke nicht dass das der Fall ist.

Ich bin das aus IntelliJ so gewohnt, dass es automatisch läuft, scheint wieder mal so eine Eclipse-Eigenheit zu sein

 

[Oneixee5]

Wir verwenden im Moment Eclipse und VSCode. Ich werde Mal bei Lombok schnüffeln wie die das machen.

 

[mrBrown]

Wir verwenden im Moment Eclipse und VSCode.

Mein Beileid.

 

[KonradN]

Ich bin das aus IntelliJ so gewohnt, dass es automatisch läuft, scheint wieder mal so eine Eclipse-Eigenheit zu sein

Ist doch in IntelliJ auch nicht anders. Es ist ja toll, wenn der Build direkt läuft, weil halt Maven dahinter steckt, aber man will ja auch die Möglichkeiten der IDE voll ausgenutzt haben. Also z.B. bei Lombok soll er wissen, was da so alles generiert wird, damit der Logger oder Getter/Setter im Editor bekannt sind und angeboten werden.

Bei Lombok fällt es nicht (mehr) auf, da IntelliJ das direkt bei der Installation mit installiert und aktiviert. Aber ich habe Lombok eine Zeit lang aus Projekten raus geschmissen, weil bei fast jeder neuen IntelliJ Version erst Tage vergehen mussten, bis auch das Lombok Plugin wieder lief.

Und der Build wird auch in Eclipse laufen, so man diesen über Maven laufen lässt und nicht irgendwas nutzt von wegen "Eclipse compiliert alles im Hintergrund mit eigenem Compiler der jetzt auch (etwas übertrieben) statt Java 1.0 auch 1.2 unterstützt")

Oder habe ich da jetzt etwas missverstanden bei der Problematik die in Eclipse und nicht in IntelliJ ist?

 

[LimDul]

Eigentlich sollte es auch in Eclipse automatisch klappen

 

[mrBrown]

Ist doch in IntelliJ auch nicht anders. Es ist ja toll, wenn der Build direkt läuft, weil halt Maven dahinter steckt, aber man will ja auch die Möglichkeiten der IDE voll ausgenutzt haben. Also z.B. bei Lombok soll er wissen, was da so alles generiert wird, damit der Logger oder Getter/Setter im Editor bekannt sind und angeboten werden.

Mit allen vernünftigen Annotation Prozessoren kann man die IDE direkt voll ausnutzen, das ist doch nur ein Problem von Lombok, weil es inoffizielle APIs auf komischen Wegen nutzt.

 

[Staarfightaar]

Mein Beileid.

wir haben in meiner arbeit Visual studio die bezahlte version mit allen drum und dran außer java packages... nö ... da nehmen wir eclipse her von 2016 mit java 8... versteh ich nicht

 

[KonradN]

Mit allen vernünftigen Annotation Prozessoren kann man die IDE direkt voll ausnutzen, das ist doch nur ein Problem von Lombok, weil es inoffizielle APIs auf komischen Wegen nutzt.

Ok, dann scheine ich bei der aktuellen Thematik hier das Problem nicht richtig erfasst zu haben. Evtl. fehlt mir da einfach die (negative) Erfahrung mit Annotation Prozessoren unter Eclipse. Aber die Problematik, die euch gerade bewusst zu sein scheint, ist wohl bisher an mir vorbei gegangen.

Die APIs, die einzelne Libraries nutzen, waren bei mir aber bisher auch noch nichts, das ich vertieft habe. Danke aber auf jeden Fall für die Hinweise.

 

[Oneixee5]

Da die IDE für manche ein Problem zu sein scheint. Die offiziellen IDE's bei uns sind Eclipse und VSCode. Das bedeutet wenn ich ein Projekt auschecke sollte es damit auch laufen. Natürlich gibt es externe Abhängigkeiten, wie Server, Datenbanken, etc. Viele JEE-Projekte sind auf den Oracle Weblogic zugeschnitten. Die Doku in den Projekten umfasst mindestens alles um mit diesen beiden IDE's so schnell wie möglich loslegen zu können. Eclipse und VSCode haben den Vorteil, dass sie zum großen Teil die gleichen Konfigurationsdateien verwenden und ohne große Lizenzprobleme schnell verfügbar sind. So ein Umfeld wird sich ganz sicher mit der Zeit verändern, im Moment ist das aber unser Stand.
Verwenden kann aber jeder was er möchte, solange die vorgenannten Bedingungen erfüllt werden. Es ist vollkommen egal ob jemand Vi oder eine selbst geschriebene IDE nutzen möchte.
Wenn aber ein Sprint ansteht darf es nicht passieren, dass plötzlich 10 Leute einen Monat brauchen um das Projekt in ihrer IDE zum Laufen zu bekommen, weil jeder andere Befindlichkeiten hat.

 

[Oneixee5]

In die IDE muss man es zwar etwas umständlich einbinden damit diese auch die Annotation anwendet,

Damit meinte ich, man muss in Eclipse das Plugin m2e-apt installieren um Annotation-Processoren für einzelne Projekte selbst einzustellen. Ist das JAR einmal bekannt funktioniert der Annotation-Processor automatisch. Auch bei javac muss der Annotation-Processor im Classpath bekannt sein und evtl. sind auch noch weiter Parameter anzuwenden.
Ich möchte das aber lieber etwas einfacher haben, ohne viel nachzulesen und Installation in der IDE. Dabei gefällt mir der Installer von Lombok schon ganz gut.

 

[KonradN]

Im Screenshot sieht man bereits den Code, der das Array mit Zufallszahlen füllt.

Und je nach notwendiger Auswertung ist kein Sortieren notwendig. Es reicht einmal durch das Array zu laufen um dann die Anzahl zu haben.

Aber unabhängig von der Bewertung der Lösung: dieses Hinklatschen einer Lösung hilft dem TE nicht, sowas in Zukunft selbst zu lösen. Ebenso eine Diskussion um eine Stream Lösung....

 

[LimDul]

Im Screenshot sieht man bereits den Code, der das Array mit Zufallszahlen füllt.

Und je nach notwendiger Auswertung ist kein Sortieren notwendig. Es reicht einmal durch das Array zu laufen um dann die Anzahl zu haben.

Aber unabhängig von der Bewertung der Lösung: dieses Hinklatschen einer Lösung hilft dem TE nicht, sowas in Zukunft selbst zu lösen. Ebenso eine Diskussion um eine Stream Lösung....

Falscher Thread?

 

[KonradN]

Falscher Thread?

Oh ja ... ich wundere mich gerade ... War auf dem Smratphone, aber dennoch wundert mich da gerade, denn beim Schreiben habe ich zurück gescrollt und war kurz davor, auch noch etwas von Jw456 zu zitieren... Daher kann ich das gerade nicht nachvollziehen.