Die Zukunft von Java auf der Oracle Code One 2018


#1

#2

Gut, Swing wird vorerst bis 2026 unterstützt, genügend Zeit, um sich mit JavaFX zu beschäftigen.


#3

Erstmal sollte Oracle das in einen brauchbaren Zustand bringen Oo.


#4

Interessant. Arbeitest du mit JavaFX? Was gefällt dir daran (noch) nicht?


#5

Wir hatten mal angefangen damit einen Client aufzubauen. Allerdings sorgte deren Binding-mechanismus damals für heftige performance-probleme. Ich hab dann mit dem Profiler rausgefunden, dass bei den Weak-Listenern die Wrapper nicht aufgeräumt werden. Als ich dann dazu google bemüht hatte, bin ich auf diesen Blog gestoßen:

http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html

Da beschreibt er das Problem nochmal + dass das Problem gemeldet wurde. Aber geschlossen mit Status: “Wont Fix”.

Wie es aktuell ausschaut. Keine Ahnung - bezweifle aber, dass das gelöst wurde.


Ein anderes Team hier hat mit dem JavaFx-Browser gearbeitet. Details hab ich keine, scheint aber auch fĂĽr Memory-Probleme gesorgt zu haben. Auf jeden Fall hat man jetzt in der Firma teuer Geld ausgegeben um eine gescheite Komponente zu haben.


Ich trau JavaFx deswegen nicht so wirklich.


#6

Nun, als alter Swing-Fan muss ich das noch aus der anderen Richtung beleuchten: Die Bindings in JavaFX sind etwas, was vieles wirklich viel einfacher machen könnte als in Swing. Die im Blog angesprochenen Nachteile kann ich nicht fundiert bewerten - ich hab’ mit JavaFX auch nocht nich wirklich viel gemacht - speziell bedeutet das natürlich auch, dass ich weeeeiiit davon weg bin, auch nur annährend so tief und ausführlich unter die Haube geschaut zu haben (und bestimmte “best practices” zu kennen) wie bei Swing.

Wenn es bei JavaFX aber Dinge gibt, die auch (!) bei “richtiger” Verwendung gravierende Probleme verursachen, ist das natürlich blöd.

Der spezielle Punkt der Weak References war vielleicht auch nur ein Versuch, das zu beheben, was bei “falscher” Verwendung von Swing ein Problem war: Ein unbedachtes

someComponent.addSomeListener(new SomeListener() { ... });

konnte leicht mal das Problem aufwerfen, dass die anonyme (!) Instanz, die da erzeugt wird, nie wieder entfernt werden kann. Speziell wenn man selbst Komponenten nach dem Swing-MVC-Paradigma aufgebaut hat:

class Model { 
    void addListener(Listener listener) { ... }
}

class View extends JComponent {
    public View(Model model) {
        model.addListener(new Listener() {
            void modelChaged() { 
                updateThisView(); 
            }
        });
    }
}

Wenn man dort ein paar mal

View view = new View(model);
view = new View(model);
view = new View(model);
view = new View(model);

gemacht hat, wurden dem Model immer mehr Listener hinzugefĂĽgt, die man nicht wegkriegen konnte. So, wie es da steht, ist das natĂĽrlich klar - das kann aber auch leicht mal vieeel versteckter auftreten! Schon der umgekehrte Fall von

view.setModel(modelA);
view.setModel(modelB);
view.setModel(modelC);

bewirkt einen Listener-TrĂĽmmerhaufen.

Die “saubere” Lösung ist in solchen Fällen (speziell für letzteres) dann eben, den (bisher anonymen) Listener in der View als Instanzvariable zu speichern und Methoden

void setModel(Model model) {
    if (this.model != null) this.model.removeListener(listener);
    this.model = model;
    if (this.model != null) this.model.addListener(listener);
}

anzubieten. (Ja, für den ersten Fall muss dann aber immernoch view.setModel(null) aufgerufen werden, um das zu erreichen, was dem dispose() im Blogbeitrag entspricht… aber ab irgendeinem Punkt muss man auch sagen, dass man den Programmierer zwar nach Möglichkeit daran hindern sollte aber eben nicht immer daran hindern kann, Mist zu machen… :confused: )


#7

Das JavaFX ein Memory leak haben soll, hatte ich bereits mehrmals gelesen, aber nie hinterfragt. Ob dass die gleichen waren wie im Blog weiĂź ich nicht. Aber die Beschwerden im Blogeintrag wĂĽrde ich jetzt nicht so hoch gewichten fĂĽr die allermeisten Anwendungen.
Wenn man eine riesige Anwendung komplett im JavaFX MVC Modell schreibt, dann okay, können schon einige Weakpointer zusammen kommen. Man muss ja nur mal überlegen das jede primitive Variable aus Wrapper Objekt und Listen an Weakpointern besteht.

Die Steuerungssoftware für unsere Roboter-Anlage schreibe ich absichtlich in Java wegen JavaFX und FXML. (Und weil ich C++ hasse wie die Pest. Diese rückständige $@/%:fire:#€!)
Früher habe ich oft Anwendungen in Swing geschrieben, aber das ziehe ich noch nicht mal mehr ins Gedächtnis.
Wer JFX aufschiebt ist selber Schuld. Komplizierteste Benutzeroberflächen lassen sich viel schneller erstellen und bestehende editieren.
Aber das und viel mehr hatte ich bereits etliche male hier und da erwähnt.


#8

Also von Speicherlecks oder Perfomanceproblemen hab ich bisher auch noch nichts gemerkt, und ich benutze wirklich viele Bindings und das auch an wahrscheinlich unpassenden stellen, wo auch viele neue erzeugt werden.
FĂĽr mich wiegen die Vorteile auch deutlich das auf was die angeblichen Nachteile sein sollen.


#9

Wir hatten die Probleme beim Anzeigen der Wetten bemerkt als wir Pagination eingebaut hatten. Du hast Haufenweise Wettmärkte auf einer Seite von denen jeder einzelne Bindings hat (war schonmal mit JavaFx gearbeitet hat, kann sich glaub vorstellen wie viele da zusammen kommen können). Anfangs lief alles noch sauber - das Problem kam wenn der Nutzer durch die Seiten geblättert hatte. Jeder Wrapper der vorherigen Seite blieb bestehen. Ein paar mal vor und wieder zurück zu gehen hat dann für massive Performanceeinbrüche gesorgt die dich zum Neustart gezwungen haben.


#10

@Marco13, zu diesem Beiträg wünsche ich mir einen kleinen Artikel im Wiki, der das konkret erklärt. :slight_smile:


#11

Das Wiki könnte sowieso mehr Artikel zu JavaFX gebrauchen :face_with_hand_over_mouth:


#12

Genau. Ich habe noch keine Zeile JavaFX geschrieben. Daher wĂĽrde ich auch mehr dazu wissen wollen.
Wenn wir hier wieder mehr Besucher haben wollen, geht das auch bestimmt mit mehr Material zu JavaFX.


#13

Ich kann mich bei Gelegenheit mal hinsetzen und ein bisschen was schreiben.
Wäre aber gut, wenn ich so ein paar Anhaltspunkte hätte, woran ich mich Orientieren sollte.


#14

Der Artikel zu “Applets in Applikationen umwandeln” ist ja auch noch pending. *verträumt ins Leere starrt* : Wäre toll, wenn man nicht arbeiten müßte. Aber ich schreib’s mal auf meine TODO-Liste :wink:


#15

Ich habe in der vergangenen Woche ein Kapitel bearbeitet: Applet-Lebensyzyklus
Hatte den geringsten Aufwand, glaube ich. :wink:


#16

Tatsächlich hatte ich kurz überlegt, ob man nicht gleich einen Artikel “Applets in JavaFX-Anwendungen verwandeln” schreiben sollte, aber erstens könnte ich da nicht sooo viel beitragen, und zweitens ist es dafür vielleicht noch zu früh :wink: