Discussion :

[bouye]

Aucun changement dans l'API, il s'agit principalement d'une amélioration des performances en diminuant la taille des runtimes JFX à télécharger, un chargement des applets et applis JavaWebStart plus rapide, une amélioration des support des navigateurs sur Mac et la correction de quelques bugs graphiques.

Release notes : http://java.sun.com/javafx/1/referen...tes-1-2-3.html

[Obligen]

Des mois et des mois que j'attends une release avec un composant d'édition de texte multi-ligne histoire de pouvoir faire autre chose que des applets de pub, et eux ils réduisent la taille des runtimes. Faudrait qu'on puisse en faire qque chose déjà !!

.NET 4 arrive très bientôt, AIR 2 aussi, et JavaFx n'a toujours pas démarré. Swing, ca commence à faire vieux et moche. Je les sens pas super bien barrés là quand même...

A la limite, si le "chargement des applets et applis JavaWebStart plus rapide", ça veut dire un chargement asynchrone dans le navigateur, histoire d'arréter de tout freezer (quand même dingue ça, vive les années 90)...

Ouais je sais, je râle, je râle, mais à force, j'ai mes raisons

[Lorantus]

Orcale aura beau dire...

Ca me fait quand même mal de voir un entête "Oracle" sur un "release note" en lien avec Java.

Avec le temps...

[pseudocode]

.NET 4 arrive très bientôt, AIR 2 aussi, et JavaFx n'a toujours pas démarré. Swing, ca commence à faire vieux et moche. Je les sens pas super bien barrés là quand même...

Je pense que JavaFX a manqué le coche. Le simple "relooking" des applets n'était pas suffisant pour concurrencer .Net et Flash.

Il fallait créer une nouvelle technologie complètement orientée web, plutot que d'adapter tant bien que mal le JRE existant en y ajoutant un enième framework. Dommage...

[Julien Bodin]

Je pense que JavaFX a manqué le coche. Le simple "relooking" des applets n'était pas suffisant pour concurrencer .Net et Flash.

Il fallait créer une nouvelle technologie complètement orientée web, plutot que d'adapter tant bien que mal le JRE existant en y ajoutant un enième framework. Dommage...

Pour ma part je pense qu'ils auraient dû conserver une syntaxe Java. C'est pour cette raison que je ne m'y suis pas intéressé.

[Traroth2]

La syntaxe n'est pas très complexe, mais parfois déroutante. Par exemple, il faut utiliser <> au lieu de !=. Pourquoi faire différent juste pour faire différent ? Ça n'apporte rien !

[bouye]

La syntaxe n'est pas très complexe, mais parfois déroutante. Par exemple, il faut utiliser <> au lieu de !=. Pourquoi faire différent juste pour faire différent ? Ça n'apporte rien !

Tu ne confondrai pas avec un autre language par hasard ?
Ou alors c'etait comme ca dans F3 ? En tout cas ce n'est pas le cas dans JavaFX.

Moi je me demande plutot pourquoi je dois utiliser or, and et not au lieu de ||, && et !.

[arno31]

C'est vrai que devoir choisir entre Java et JavaFx au lieu de pouvoir mixer les 2 naturellement n'est vraiment pas une bonne idée.
J'ai lu qu'il y avait des astuces pour utiliser les 2 en même temps tout de même mais cela reste du bricolage apparemment.

[bouye]

Ben euh... si on est dans un projet JavaFX, mixer du Java dans du JavaFX se fait tout naturellement et ca se fait SUPER facilement.
Mixer du JavaFX dans du Java est egalement naturel si on utilise les mecanismes d'heritage... et si on est toujours dans un projet JavaFX. Sauf cas tres particlier (en general des conflits sur l'inference de type lorsqu'on apelle ou surcharge des methodes avec des signatures voisines), ca passe bien.

Mixer du JavaFX dans du Java au niveau graphique pour l'afficher dans Swing est plus... difficile a atteindre...
Rajouter du JavaFX dans un projet pur Java est tout de suite bien plus tordu.