SuppressWarnings
erweitern, weil das mit @interface
s nicht geht.SuppressWarnings
an der Stelle steht.@SuppressWarnings(value = { "unused", "reason:Weil es Seiteneffekte hat." })
Findbugs setzen wir nicht, wir verwenden Sonarlint. Das hätte ich evtl. erwähnen können. Trotzdem danke!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.
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.Bei einem guten Entwicklerteam sieht das auch jeder ein
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.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.
@SuppressWarnings("unused")
@SuppressWarningsDocumentation("suppress warnings documentation")
.../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
Wenn das in Maven als Annotation Processor eingebunden ist, sollte das doch auch in den meisten IDEs automatisch gehen?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?
Ich bin das aus IntelliJ so gewohnt, dass es automatisch läuft, scheint wieder mal so eine Eclipse-Eigenheit zu seinZumindest 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.
Mein Beileid.Wir verwenden im Moment Eclipse und VSCode.
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.Ich bin das aus IntelliJ so gewohnt, dass es automatisch läuft, scheint wieder mal so eine Eclipse-Eigenheit zu sein
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.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.
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 nichtMein Beileid.
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.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.
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.In die IDE muss man es zwar etwas umständlich einbinden damit diese auch die Annotation anwendet,
Falscher Thread?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....
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.Falscher Thread?