[teamfx] Re: "Performance einzelner Controls" - aus Danny Althoff: Re: Trotzdem weitermachen ;-) ?

  • From: Hendrik Ebbers <hendrik.ebbers@xxxxxxxxx>
  • To: teamfx@xxxxxxxxxxxxx
  • Date: Tue, 22 Dec 2015 13:00:42 +0100

Hi,

hatte gestern auch was gebastelt und das ganze grad mal fix in der Mittagspause
mit Alex Beispiel gemergt:
https://gist.github.com/hendrikebbers/eb87093510b1f8e80415

Hier kann man sich angucken wie der Unterschied bei Komponenten ist (Button
deutlich schneller als Textfeld) und was es bringt die Erstellung in den
Hintergrund zu verlagern.

Durch mehrmaliges Hinzufügen / entfernen kann man auch schön sehen, wie viel
schneller das ganze durch JIT wird (Erste Durchgang 3000 Sekunden, 3 Durchgang
500 Sekunden).

Gruß,

Hendrik


Am 22.12.2015 um 11:37 schrieb Dirk @ Google <dlemmermann@xxxxxxxxx>:

Danke für das Update Alex.

Komisch finde ich nur, dass „needsLayout“ ständig wechselt zwischen true und
false wenn ich das Fenster in den Hintergrund oder Vordergrund bringe. Finde
ich jetzt auf Anhieb nicht einleuchtend. Es ändert sich ja nichts am Fenster,
die Grösse ist gleich. Warum sollte irgend ein Layout notwendig sein, nur
weil das Fenster nach vorne gebracht wird?

Dirk


Am 22.12.2015 um 11:30 schrieb Casall, Alexander <alexander.casall@xxxxxxxxx
<mailto:alexander.casall@xxxxxxxxx>>:

Ich habe das Beispiel mit den TextFields noch mal etwas umgebaut. Man kann
jetzt die Zeit messen, ohne selbst auf den Button zu drücken und oben im
Supplier den Node tauschen, der auf Performance getestet werden soll.

https://gist.github.com/sialcasa/359746fcb01d36ddefa0
<https://gist.github.com/sialcasa/359746fcb01d36ddefa0>

VG
Alex

Von: <teamfx-bounce@xxxxxxxxxxxxx <mailto:teamfx-bounce@xxxxxxxxxxxxx>> im
Auftrag von Markus KARG <markus@xxxxxxxxxxxxxxx
<mailto:markus@xxxxxxxxxxxxxxx>>
Organisation: Markus KARG, Staatl. gepr. Inf.
Antworten an: "teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>"
<teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>
Datum: Dienstag, 22. Dezember 2015 10:43
An: "teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>"
<teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>
Betreff: [teamfx] Re: "Performance einzelner Controls" - aus Danny Althoff:
Re: Trotzdem weitermachen ;-) ?

Björn,

mal ganz ehrlich: Alleine die Diskussion um Workarounds ist lächerlich. Im
Jahre 2015 erwartet man als Programmierer doch schlicht und ergreifend, dass
ein Gerät mit 3+ GHz, vier Kernen, zig CUDA cores, 12 GB RAM, etc. in der
Lage ist, ein paar lächerliche Textfelder binnen einer Sekunde auf den
Bildschirm zu pinseln… alles andere nenne ich schlicht "Konstruktionsfehler"
(und vermutlich halten uns sämtliche Kunden für bekloppt, wenn wir denen
ernsthaft sagen, dass JavaFX das nicht schneller hinbekommt).

-Markus

From: teamfx-bounce@xxxxxxxxxxxxx <mailto:teamfx-bounce@xxxxxxxxxxxxx>
[mailto:teamfx-bounce@xxxxxxxxxxxxx <mailto:teamfx-bounce@xxxxxxxxxxxxx>] On
Behalf Of Björn Müller
Sent: Dienstag, 22. Dezember 2015 10:25
To: teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
Subject: [teamfx] Re: "Performance einzelner Controls" - aus Danny Althoff:
Re: Trotzdem weitermachen ;-) ?

Servus zusammen,

ich habe nun einen Bug Report bei Orcale abgesendet, zur Zeit noch unter der
internen Nummer "JI-9027741". Der Bug durchläuft nun ein Review-Verfahren
und wird dann hoffentlich mit einer offiziellen Bug Id versehen. Wenn diese
kommt, gebe ich sie natürlich bekannt. - Leider kann ich im Moment die im
Bug-Formular eingetippten Informationen nirgendwo einsehen - sonst hätte ich
sie ans Mail angehängt...

Noch zum Thema (ich hatte es auch schon einmal erwähnt): wir rendern im
Moment unsere TextField-Instanzen in Massenszenarien als Text-Instanzen aus
- und schalten dann beim Focussieren um. Das hat natürlich Nachteile bzgl.
Usability (der Benutzer erwartet, dass der Cursor sich
dort befindet, wo er hindrückt), die Vorteile der wesentlich besseren
Performance schlagen diese jedoch...

Ganz allgemein will ich aber so etwas gar nicht machen. Ich "weigere" mich
innerlich, ein TextField als "heavy object" anzuerkennen...

Viele Grüße! Björn



Am 21.12.2015 um 19:56 schrieb Markus KARG:
Stimmt, ich erinnere mich daran, dass das irgendwann sogar mal als best
Practice in Google's Android SDK erwähnt wurde.
-Markus

From:teamfx-bounce@xxxxxxxxxxxxx <mailto:teamfx-bounce@xxxxxxxxxxxxx>
[mailto:teamfx-bounce@xxxxxxxxxxxxx <mailto:teamfx-bounce@xxxxxxxxxxxxx>]
On Behalf Of Anton Epple
Sent: Montag, 21. Dezember 2015 19:14
To: teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
Subject: [teamfx] Re: "Performance einzelner Controls" - aus Danny Althoff:
Re: Trotzdem weitermachen ;-) ?

So was ähnliches habe ich bei einem Kunden gemacht, der richtig „teure“
Controls hatte, aber noch einfacher: Beim ersten Start von den Nodes einen
Snapshot machen und speichern. Beim nächsten mal, erst den Snapshot in
einem ImageView anzeigen und dann gegen das echte Control ersetzen. Ist ein
Standardtrick aus der mobilen Welt.



Von: <teamfx-bounce@xxxxxxxxxxxxx <mailto:teamfx-bounce@xxxxxxxxxxxxx>> on
behalf of Benjamin Gudehus <hastebrot@xxxxxxxxx
<mailto:hastebrot@xxxxxxxxx>>
Antworten an: <teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>
Datum: KW 52,Montag, 21. Dezember 2015 um 19:07
An: <teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>
Betreff: [teamfx] Re: "Performance einzelner Controls" - aus Danny Althoff:
Re: Trotzdem weitermachen ;-) ?

Idee: Vielleicht kann man ja anstatt eines richtigen `TextField`s einfach
eine `Region` die so aussieht (mit ähnlichen CSS-Stilen und evtl. auch
Text) erstellen und dann nach und nach mit richtigen `TextField`s ersetzen.

2015-12-21 19:01 GMT+01:00 Benjamin Gudehus <hastebrot@xxxxxxxxx
<mailto:hastebrot@xxxxxxxxx>>:
Zumindest kann man die ganzen Berechnungen in `buildControlsOneByOne()`
einlagern, indem man zusätzlich zu

TextField f = new TextField();

noch

f.setSkin(new TextFieldSkin(f));
f.applyCss();

einfügt.

Die Methode allein benötigt dann 5s statt 500ms bei mir; wobei (egal ob
vorherige oder diese Kombination) es immer knapp 5s dauert, bis die
TextFields angezeigt werden.

--Benjamin

2015-12-21 16:55 GMT+01:00 Markus KARG <markus@xxxxxxxxxxxxxxx
<mailto:markus@xxxxxxxxxxxxxxx>>:
Schade, dass in dem Vortrag nicht wirklich etwas Verwertbares mitgeteilt
wurde. :-(

JavaFx scheint intern so kompliziert zu sein, dass nichtmal Oracle sagen
kann, was man tun muss, wenn man zig TextFields benutzen, aber nicht
mehrere Sekunden warten will. ;-)

-Markus

From:teamfx-bounce@xxxxxxxxxxxxx <mailto:teamfx-bounce@xxxxxxxxxxxxx>
[mailto:teamfx-bounce@xxxxxxxxxxxxx <mailto:teamfx-bounce@xxxxxxxxxxxxx>]
On Behalf Of Benjamin Gudehus
Sent: Montag, 21. Dezember 2015 14:31
To: teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
Subject: [teamfx] Re: "Performance einzelner Controls" - aus Danny Althoff:
Re: Trotzdem weitermachen ;-) ?

Da passiert ja schon mehr in einem JavaFX TextField als in einem Swing
TextField, oder?

Übernimmt das bei Swing nicht teilweise auch das Betriebssystem? Naja, der
Layout- und CSS-Pass ist bei JavaFX so ausschlaggebend. Da kann man
bestimmt noch etwas optimieren. Einer vom Google Chrome Team hat mir das
auch bestätigt, dass Relayouts sehr kostspielig sind. Der Vorteil bei
Chrome sind aber sicherlich die eingebauten Entwicklerwerkzeuge für
Performancemessung und -visualisierung. Ich hatte da mal ein wenig versucht
Logger einzubauen, um dann die Messungen wahlweise in Textdateien,
System.out oder über einen Socket auszugeben.

Apropos Renderer-Optimierung: Auf der JavaOne 2013 gab es von Oleg Mazurov
den Vortrag “Optimizing JavaFX Applications”. Eigentlich absolut essentiell
zum Verständnis von JavaFX Application und Renderer Thread, jedoch leider
im Netz bisher schwer zugänglich gewesen. Der Vortrag ist mittlerweile
endlich auch auf YouTube angekommen
(https://www.youtube.com/watch?v=dw8se4uA1qc
<https://www.youtube.com/watch?v=dw8se4uA1qc>); PDF-Folien sollten auch gut
auffindbar sein; Parleys (wo der Vortrag ursprünglich abrufbar war) ist ein
bisschen komisch mit der Rausgabe von Videos und PDFs.




2015-12-21 13:59 GMT+01:00 Dirk @ Google <dlemmermann@xxxxxxxxx
<mailto:dlemmermann@xxxxxxxxx>>:
Auch wahr.

Vielleicht ist es schlicht und einfach die Komplexität von JavaFX Controls.
Da passiert ja schon mehr in einem JavaFX TextField als in einem Swing
TextField, oder? Zum einen durch die Verwendung von CSS, zum anderen durch
das ganze Property Binding. Selbst wenn man CSS noch schneller machen
könnte, wäre so ein JavaFX Textfield sicherlich fetter als ein Swing
Textfield und ein Vergleich der selbigen miteinander nicht unbedingt fair.
Swing war für Rechenleistung von 1996 entwickelt worden, JavaFX für heutige
Maschinen.

Just thinking out loud ….

Dirk


Am 21.12.2015 um 13:54 schrieb Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx
<mailto:tom.schindl@xxxxxxxxxxxxxxx>>:

Genau das war auch mein test damals um zu zeigen, dass es nicht der SG
ist sondern Layout-Pass & CSS wobei der Layout-Pass bei Shapes auch sehr
einfach ist ;-)

Tom

On 21.12.15 13:52, Dirk @ Google wrote:
Bei mir war das ähnlich. Wollte damals für FlexGanttFX alle Balken als
Nodes realisieren. Die Zeit ging hauptsächlich bei der Anwendung von CSS
verloren. Am Scenegraph liegt es wohl weniger. Wenn man bei diesem Test
einen „einfachen“ Node wie Rectangle verwendet (also keine Skins, wenig
CSS), dann ist alles blitzschnell da.

Dirk

Am 21.12.2015 um 13:49 schrieb Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx
<mailto:tom.schindl@xxxxxxxxxxxxxxx>>:

Hallo,

Ich hatte einen ähnlichen Fall einmal mit the PulsLogger betrachtet und
die Zeit ging zu ca 70% im CSS verloren und zu 30% im layout pass.

Tom


On 21.12.15 13:47, Dirk @ Google wrote:
Ja danke, ich hab’s inzwischen. Bin schon am profilen.

Am 21.12.2015 um 13:46 schrieb Markus KARG <markus@xxxxxxxxxxxxxxx
<mailto:markus@xxxxxxxxxxxxxxx>
<mailto:markus@xxxxxxxxxxxxxxx <mailto:markus@xxxxxxxxxxxxxxx>>>:

War als Anhang an Björn's Mail dran.
-Markus

*From:* teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>
<mailto:teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>>
[mailto:teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>] *On Behalf Of *Dirk @ Google
*Sent:* Montag, 21. Dezember 2015 10:52
*To:* teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
<mailto:teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>
*Subject:* [teamfx] Re: "Performance einzelner Controls" - aus Danny
Althoff: Re: Trotzdem weitermachen ;-) ?

Code? Möchte es gerne auf meinem Mac ausprobieren.

Dirk


Am 21.12.2015 um 09:13 schrieb Björn Müller
<bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>>>:


...also ich mach' das hyper-pragmatisch: große Anzahl von Controls
erzeugen und Zeitmessung durch expliziten Button, wenn die Controls
sichtbar sind. ;-)
Mini Programm im Anhang. In der Console werden dann entsprechende
Zeiten ausgegeben.

<cegageib.png>
Bei mir (Pentium i7, 3.1GHz) dauert der Erstaufbau von 3000 Controls
knapp 3000ms. Nach clearen, kostet dann der Zweitaubau 1.300ms.

Viele Grüße! Björn

Am 21.12.2015 um 08:51 schrieb Benjamin Gudehus:
Am Rande eine kleine Frage:
Genaue Messungen und Szenarien kann ich gerne nachreichen, erstmal
will ich mal schauen, wie bei Euch die Stimmungslage hier ist.
Wie messt ihr die Zeitspanne für den Aufbau der Nodes? Soweit ich
weiß kam man das auch nur per scene und es muss auf private fields
zugegriffen werden.
-Benjamin
On Dec 18, 2015 10:17 PM, "Casall, Alexander"
<alexander.casall@xxxxxxxxx <mailto:alexander.casall@xxxxxxxxx>
<mailto:alexander.casall@xxxxxxxxx
<mailto:alexander.casall@xxxxxxxxx>>> wrote:
Hey Björn,

Hast du neue Erkenntnisse bzw. eine Bug-ID?

VG
Alex

*Von: *<teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>
<mailto:teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>>> im Auftrag von Björn Müller
<bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>>>
*Antworten an: *"teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
<mailto:teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>"
<teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
<mailto:teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>>
*Datum: *Mittwoch, 25. November 2015 19:08
*An: *"teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
<mailto:teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>"
<teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
<mailto:teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>>
*Betreff: *[teamfx] Re: "Performance einzelner Controls" - aus Danny
Althoff: Re: Trotzdem weitermachen ;-) ?

...ja, und zwar hier konkret das Erzeugen des Skins zur Instanz. Bin
gerade am Zusammenkehren meiner PerformanceTests + Messungen und
mache daraus bzgl. des TextFields mal eine ordentliche JIRA-Meldung
draus. Wird aber erst morgen gegen späteren Nachmittag/Abend sein,
da unterwegs...

Mehr Threads beim Erzeugen der Instanzen? Müssen die nicht im
FX-Thread erzeugt werden?
Sei's drum: Textfelder sind aus meiner Sicht immer noch
ziemlich-lightweight Controls. ;-)


Freundliche Grüße! Björn

------------------------------------------------------------------------
Björn Müller
+49 (0) 6223 484147, bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>>
CaptainCasa GmbH, Hindemithweg 13, D-69245
Bammental, http://www.CaptainCasa.com <http://www.captaincasa.com/>
<http://www.captaincasa.com/ <http://www.captaincasa.com/>>
------------------------------------------------------------------------

Am 25.11.2015 um 18:57 schrieb Markus KARG:
Damit ich es richtig verstehe: Ist das *Erzeugen* der Instanzen ein
Problem (lässt sich ja mit mehr Threads kompensieren) oder die
Nutzung zur Laufzeit?
-Markus


*From:*teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>
<mailto:teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>>
[mailto:teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>] *On
Behalf Of *Björn Müller
*Sent:* Mittwoch, 25. November 2015 09:34
*To:* teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
<mailto:teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>
*Subject:* [teamfx] "Performance einzelner Controls" - aus Danny
Althoff: Re: Trotzdem weitermachen ;-) ?


Hi zusammen,

@ "es GIBT Probleme mit der Performance einzelner Elemente" aus
untiger Meldung:

Ganz konkret ist aus meiner Sicht das *TextField*miserabel (bzw.
alles, was unter TextInputControl liegt). Wir haben Szenarien, in
denen durchaus mal 600 (und mehr) Textfelder aufgebaut werden.
Unter Swing war das problemlos, unter FX eine Sache von deutlich
mehreren 100ms. Es geht mir um die Performance beim Aufbauen des
Dialogs - es geht nicht um die Bedienperformance, wenn die Felder
mal stehen.

*Ist dieses Problem auch bei Euch relevant?
Gibt es da irgendwelche Aktivitäten im FX Bereich?
*
Genaue Messungen und Szenarien kann ich gerne nachreichen, erstmal
will ich mal schauen, wie bei Euch die Stimmungslage hier ist.

Wir sind mittlerweile dazu übergegangen, in solchen
"Massen"-Szenarien das TextField-Control nur dann zu rendern, wenn
es den Focus bekommt - und sonst ein sparsames Text-Control zu
verwenden. Dies ist aus meiner Sicht aber keine optimale Lösung -
ich wehre mich etwas dagegen, ein TextField als teure Resource zu
betrachten!

Wenn aus Eurem Feedback eine gemeinsame Relevanz ablesbar ist, dann
wäre das aus meiner Sicht ein konkreter inhaltlicher Punkt, sich
dort gemeinsam abzustimmen. - Und wenn's keine gemeinsame Relevanz
gibt, dann betreiben wir hier eben weiter unser
Focus-Text-TextField-Switchen... ;-)

Freundliche Grüße! Björn

PS: da dieses meine erste Wortmeldung ist, will ich nicht versäumen
zu erwähnen: Markus - Danke für Aufbau und Organisation der ersten
Schritte!

------------------------------------------------------------------------
Björn Müller
+49 (0) 6223 484147, bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>>
CaptainCasa GmbH, Hindemithweg 13, D-69245
Bammental, http://www.CaptainCasa.com
<http://www.captaincasa.com/> <http://www.captaincasa.com/
<http://www.captaincasa.com/>>
------------------------------------------------------------------------

Am 25.11.2015 um 09:05 schrieb Danny Althoff:

Hi Jens, hi Markus, hallo Mailingliste,

vielen Dank für das Teilen des Artikels. Es ist hilfreich die
Meinung von anderen zu diesem Thema einzuholen, damit alle
Sichtweisen ihr Gehör bekommen.

Wieso der Artikel IMHO nicht gut ist:
- es werden falsche Metriken verglichen, der bloße Vergleich der
"Trends" von Google ist wenig aussagekräftig, da nicht
eingeflossen ist, ob es sich hier um Probleme handelt, oder aber
um technische Dokumentation (was nicht gut dokumentiert ist,
erzeugt ebenfalls solche Suchhits)
- wenn JavaFX eben nicht die alten fehlerhaften Konzepte
verfolgen sollte (by Design), dann ist es auch verständlich, dass
hier nicht sofort jeder aufspringt, weil es eben NICHT so schnell
mit alten Swing/AWT-Kern gedanklich matched
- es fehlt eine komplette Betrachtung der JavaScript-Welt,
gerade mit AngularJS und JQuery sowie dem Wandel mit HTML5 sind
viele Dinge von Applets und Flash weggewandert, somit gilt auch
hier ein weiterer "Personenkreis" als abgeworben/verloren (ich bin
selber jemand, der in beiden Welten unterwegs ist, als JS und Java
:P nicht Flash/Applets)

Was aber auch wahr ist im Artikel:
- es fehlt an einer klaren Werbestrategie und einer klaren
Roadmap, durch meine Arbeit am JavaFX-Maven-Plugin stolper ich
umso häufiger auf halb-fertige Ansätze, Änderungen welche nicht
sofort ersichtlich sind, sowie einer ungewohnt verstreuten Architektur
- es GIBT Probleme mit der Performance einzelner Elemente, da
diese unterschiedlich nativ gebaut/angepasst sind
- der ganze Artikel gehört zur Kategorie "RANT", und genau als
solches sollte man diesen auch ansehen
- Flash und Applets sind tot und gehören eingemottet
- weiterhin muss Java unter seindem "Experiment" der
Java-Applets leiden, ist einfach zu traumatisch gewesen


Was mich persönlich stört ist die fehlende Richtung (z.B. alles
was AWT/Swing kann, plus noch viel mehr und "schöner"?!) und den
Release unfertiger Teile. Die Aufsplittung in "JavaFX ist
opensource" hingegen erachte ich für eine falsche
Herangehensweise, denn OpenSource heißt für mich nicht nur die
Offenlegung des Quelltextes sondern auch die Akzeptanz einer
Teilnahme der Community. Klar, wir bauen die Werkzeuge dafür, oder
promoten diese Technik, aber sie ist als Ganzes vom OracleJDK zu
sehen. JavaFX ist nun im Kern von Java enthalten, daher ist die
Betrachtungsweise eines Zusatzes falsch. Mag historisch begründet
sein, war ja auch wirklich ein zusätzlich installierbares Paket
(und ist es bei OpenJDK + OpenJFX weiterhin so), aber alle JDKs
sind nicht mehr so.

Was mich aber freut ist überhaupt die Möglichkeit "von Hause aus"
native Launcher erstellen zu können oder aber ganze Bundles zu
bauen, das ist sogar der Grund, wieso ich mir nach dem Reinfall
mit JavaFX 1.x/2 zurück zu JavaFX 8 gekommen bin. Die
Möglichkeiten sind erstaunlich, wenn auch etwas wenig beworben.

Fazit: es gibt kritische Stimmen, aber das ist gut, es hilft
besser zu werden ;) also lasst es uns besser machen!


Schönen Gruß an den Rest
Danny


Am 24.11.2015 um 23:04 schrieb Markus KARG:

Jens,



ich halte den Artikel für eine sehr einseitige und grundlos
pessimistische Betrachtung. Der Bedarf für JavaFX ist da, und
Oracle bezahlt faktisch eine ganze Menge an Menschen, die daran
arbeiten. Nur sieht Oracle keinen kommerziellen Nutzen und
begrenzt daher die Menge an Mitarbeitern auf "weniger als uns lieb
ist". Aber ist es denn Oracle's *alleinige* Aufgabe JavaFX zu
entwickeln? Ich meine, es ist ja Open Source... Oracle ist an der
Hilfe durch TeamFX sehr interessiert, und meine persönliche
Erfahrung ist, dass JavaFX auch stark nachgefragt wird -- aber
eben nur dort, wo ein Fat Client gewünscht ist, nicht dort, wo man
"nur" einen Rich Client benötigt -- das sind nunmal aber zwei
verschiedenen Paar Stiefel. Was also will der Autor erreichen? Das
ist mir ehrlich gesagt unklar!



Ich werde demnächst nochmals ein Gespräch mit Kevin haben zur
Klärung, wie es weitergeht. Bis dahin hake ich den in sich
inkonsistenten und nicht wirklich wahrheitsgemäßen Artikel einfach ab.



-Markus





*From:*teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>
<mailto:* <mailto:*>teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>>
[mailto:teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>]
*On Behalf Of *Jens Deters
*Sent:* Sonntag, 22. November 2015 18:16
*To:* teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
<mailto:teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>
*Subject:* [teamfx] Trotzdem weitermachen ;-) ?




Should Oracle Spring Clean JavaFX?


Why JavaFX hasn't taken off, and what Oracle can do to
improve it's place in the ecosystem.

“Todays students sometimes learn JavaFX or Swing in class and
often find out that they learned yesterdays technologies as they
leave the classroom!“



"I think that the most important thing to do here is to move
students off of JavaFX and into more sustainable areas in Java
such as the newer server/HTML frameworks or to mobile, this will
still provide some of the pleasurable "tingle" of seeing your UI
run but would provide a more sustainable skill set."





https://dzone.com/articles/should-oracle-spring-clean-javafx
<https://dzone.com/articles/should-oracle-spring-clean-javafx>





— Jens










--



Björn Müller
CaptainCasa GmbH, Hindemithweg 13, D-69245 Bammental
+49 (0) 6223 / 484147
bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>>
<Test_91_Performance.java>


--
Thomas Schindl, CTO
BestSolution.at <http://bestsolution.at/> EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/ <http://www.bestsolution.at/>
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck





--
Thomas Schindl, CTO
BestSolution.at <http://bestsolution.at/> EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/ <http://www.bestsolution.at/>
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck







--



Björn Müller
CaptainCasa GmbH, Hindemithweg 13, D-69245 Bammental
+49 (0) 6223 / 484147
bjoern.mueller@xxxxxxxxxxxxxxx <mailto:bjoern.mueller@xxxxxxxxxxxxxxx>

Other related posts:

  1. Home
  2. teamfx
  3. Archive
  4. 12-2015