Also im Grunde ist es fast egal, ob er Swing, AWT oder JavaFX oder SWT oder gar QT Jambi nimmt. Wichtig ist es, die Konzepte zu lernen. Auch Konzepte, wie man Code strukturiert, wie man Code wartbar und testbar macht. Aber Lernen ist ein progressiver, kontinuierlicher Vorgang, aber es baucht halt Zeit.
Und ja, wenn ich nichts davon beherrschen würde (ironischerweise beherrsche ich davon JavaFX sogar am wenigsten), dann würde ich heute wohl am ehesten JavaFX nehmen, weil wie jemand schon sagte, es von manchen Konzepten deutlich näher an anderen moderneren UI-Frameworks ist.
Interessant finde ich den Vorwurf, dass JavaFX nicht mehr zeitgemäß sei, gleichzeitig aber auf Swing verwiesen wird mit Beispielen, die laut Oracle auf JDK8 basieren...
Und zum Debuggen: Ich sage auch, dass Debugging keine Fähigkeit ist, auf die man stolz sein sollte oder worin man sich gezielt einarbeiten sollte. Aber: wenn man nach Fehlern sucht, dann ist es nun mal ein gehbarer Weg. Und ich verstehe nicht, was es den TE juckt, ob Leute auf dem Jenkins debuggen können oder nicht (habe das aber auch nur überflogen).
Warum man kein Experte im Debugging sein sollte: Naja, wenn man viel mit dem Debugger arbeiten muss, dann scheint man wohl Probleme zu haben, korrekten Code zu schreiben...
Um in diesem Fall das Verhalten der Anwendung zu prüfen, dafür braucht man aber kein tiefes Debugging-Wissen. Und wenn ich mal Unit-Tests reparieren muss, weil ein Kollege nicht darauf geachtet hat, dass sein Bugfix in jahrealtem Code eben diese bricht, und ich aus dem Urlaub komme und der Kollege weg ist, und auch sonst niemand im Team sich mit dem Test auskennt, dann bringt es mir wenig, wie gut mein Code ist. Warum das überhaupt mit kaputten Unit-Tests gemerged werden konnte, keine Ahnung mehr, war mir an der Stelle auch egal weil es nichts zur Lösung beigetragen hat. Und mittels Debugger und jemand, der sich ein wenig fachlich zu der Korrektur auskannte, konnten wir dann gemeinsam den Test fixen.
Und natürlich hätte ich auch 20 Konsolenausgaben machen können, aber wenn ich so wenig Ahnung habe, was da passiert, dann weiß ich ja nicht mal, was ich ausgeben soll.
Ansonsten finde ich Ausgaben bei Tests, die den Testablauf nachvollziehbar machen, auch gar nicht schlecht. Einerseits interessiert mich häufig der Zustand vor und nach einer Operation, und ja, man kann solche Ausgaben ja auch in Testergebnissen einer Build-Pipeline sehen. Ideal ist es ja, wenn man anhand des Testlaufs/-ergebnisses schon auf den Fehler schließen kann. Klingt banal, aber ich sehe in unserer Code-Basis auch Asserts wie assertTrue(list.contains(element));. Und ja, früher habe ich auch solche Asserts geschrieben. Noch schlimmer, auch schon gesehen assertTrue(actual.equals(expected));. Da freut man sich, wenn man im Testprokoll auf dem Jenkins siehst: "expected true, but was false".
Und ich verstehe leider, dass Tests oft schlechte Asserts haben, denn die Assserts schreiben die meisten Leute dann, wenn der Test erfolgreich durchläuft... ein schlechter Assert ist kein Problem für das Jetzt, sondern für die Zukunft...
Natürlich kann der TE in seinen Code an diverse Stellen den Zustand ausgeben. Aber selbst das mache ich meist erst dann, wenn ich mit dem Debugger nicht so leicht ans Ziel komme. Dass man hier mit dem Debugger nicht leicht ans Ziel kommt, das bezweifle ich aber sehr stark.
