Discussion :

[Idelways]

JavaFX 2.0 : vers une première bêta publique ce printemps
La plate-forme écarte son langage de script et se rapproche des langages de la JVM



Oracle vient d'annoncer la sortie d'une première version bêta publique dès ce printemps pour JavaFX 2.0, la prochaine version majeure de l'environnement de développement d'applications client riches en Java.

Cette version se concentre, d'après sa feuille de route, sur l'intégration des API Java pour JavaFX, les hautes performances graphiques de son nouveau moteur de rendu, la lecture des médias et l'intégration du contenu HTML dans les applications JavaFX.
Les contrôles d'interface utilisateur et le déploiement devraient être, eux aussi, améliorés.

Avec l'arrivée des APIs Java, les développeurs pourront réaliser des applications sans devoir apprendre le langage de script de JavaFX et profiter pleinement des fonctionnalités puissantes du langage Java comme les génériques, les annotations et le multi-threading.

Ces mêmes API devraient permettre aux développeurs Web d'utiliser d'autres langages populaires comme JavaScript, JRuby, Groovy et d'autres langages qui s'exécutent sur la machine virtuelle Java (JVM) comme Scala.
Continuer d'utiliser le langage de script de JavaFX restera toutefois possible grâce au projet Visage qui devrait offrir un langage dédié pour la création d'interfaces utilisateurs.

Les API Java pour JavaFX 2.0 seront une variation sur les propriétés et listeners JavaBeans. Elles seront conçues pour fonctionner correctement avec les expressions lambda des futures versions de Java.


Source : la feuille de route de JavaFX 2.0

Et vous ?

Attendez-vous la sortie de JavaFX 2.0 ?
Cette version a-t-elle encore d'après vous des chances de s'imposer face à Silverlight et Flex ?

[jayfaze]

ah bah ca a l'air bien

La plate-forme écarte son langage de script et se rapproche des langages de la JVM

Enfin !



Vivement que la beta sorte que je teste. Car la version actuelle de javaFX, bah .... je la trouver tres pourrave

[lunatix]

javaFX 2.0 semble vraiment pas mal. Il se place plus en remplacement de swing que en concurrent de flash.
En clair, ca semble etre le swing2.0 tant attendu dans le monde java.

[Uther]

A première vue je serais plutôt de l'avis de lunatix, il semble corriger des manques cruel de Java.

Mais le problème est justement là : tout ceci aurait mérité d'arriver directement dans Java et pas à part. On a une plateforme supplémentaire(et propriétaire) à rajouter en plus de la JVM existante.

La JVM étant déjà haïe (a plus ou moins juste titre) des développeurs Web, je lui prédit un avenir funeste en tant que concurrent de Flash et Silverlight.
Pour des applications Desktop lourde, vu la réputation de Swing(la encore partiellement méritée), il ne pourra de toute façon pas faire pire.

[jayfaze]

La JVM étant déjà haïe (a plus ou moins juste titre) des développeurs Web

Ah bon ? tu veux dire pour les applet java ou bien pour les servlet/jsp/bean ?

Pour ce qui est de remplacer swing, c'est clair que ca ne peut etre que benefique.

Sinon en tant que concurrent a flash/silverlight, je pense le plus gros danser vient de l'html5. Mais faut que la W3C se presse un peu.

[Uther]

Oui je parlais des applets.
Je n'ai pas regardé en profondeur ce que permettait JavaFx, mais il me semble qu'il s'agit avant tout d'une techno coté client, pas serveur.

[Népomucène]

C'est déjà pas mal qu'Oracle n'ai pas laissé tombé JavaFx

[ZeRevo]

Je travaille actuellement sur un projet comportant une applet en java et je me demande ce que javaFX apporterait par rapport à ma solution actuelle.
Est-ce que JavaFX est une réécriture complète ou est-ce un changement de grammaire ?

[yostane]

Je crois que JavaFX était s'est un peu égaré car il promettait de faire trop de choses. En plus il y a eu l'arrivée d'Android qui a donné un grand coup à javaFX pour mobiles.

[jayfaze]

Oui je parlais des applets.
Je n'ai pas regardé en profondeur ce que permettait JavaFx, mais il me semble qu'il s'agit avant tout d'une techno coté client, pas serveur.

Oui JavaFX est coté client.

Sinon pour les applets c'est dommage. Car en plus y'a la lib pulpcore http://www.interactivepulp.com/pulpcore/widgets/ qui permet de faire des ruc pas mal avec des applets.

Je travaille actuellement sur un projet comportant une applet en java et je me demande ce que javaFX apporterait par rapport à ma solution actuelle.
Est-ce que JavaFX est une réécriture complète ou est-ce un changement de grammaire ?

JavaFx a son propre language de script. Et beaucoup de monde, moi y compris, trouve pas ca terrible.

Oracle va justement permettre de faire du javaFx avec le langage java standard. Et je suis impatient de voir ce que ca va donner.

[ZeRevo]

Oracle va justement permettre de faire du javaFx avec le langage java standard. Et je suis impatient de voir ce que ca va donner.

C'est prévu dans la version 2.0?

[jayfaze]

C'est prévu dans la version 2.0?

Oui ! Ca a été annoncé lors de la derniere javaOne. Et on pourra toujours développer avec les scrit javaFx de base. Donc ca laisse le choix.

[Traroth2]

Enfin un retour à la raison, si tout va bien !

[bouye]

On pourra toujours si le projet visage avance un tant soit peu puisqu'il s'agit desormais d'une initiative OpenSource plutot que d'un projet mene par Oracle et que dernierement Stephen Chin semblait plutot interresser de faire fonctionner Visage (donc le language F3/JavaFXScript) avec Android plutot qu'avec JavaFX 2.0 (l'API).

Super ! Au rythme ou nos services corporate et IT sont en train d'examiner le dossier de candidature au JavaFX Partner Programme fourni par Oracle, ils seront remplis et expedies au moment ou JavaFX 2.0 deviendra publique

Par contre, j'chuis pas sur que ca soit interressant de le mettre en actualite recente vu que ca fait des lustres qu'on est au courant (planning de la JavaOne + maj de la roadmap il y a 1+ mois deja).

[lequebecois79]

la grande question, c'est que fera oracle avec swing....

[Uther]

Ça fait plus de 7 ans qu'il n'assurent que le service minimum, il y a encore moins de raison que ça change.

Les seules vraies évolutions prévues pour awt/swing visent à améliorer la compatibilité avec JavaFX.

[Philippe Bastiani]

Ça fait plus de 7 ans qu'il n'assurent que le service minimum, il y a encore moins de raison que ça change.

Les seules vraies évolutions prévues pour awt/swing visent à améliorer la compatibilité avec JavaFX.

C'est clair que Swing n'a pas évolué d'un poil depuis bien 7 ans...

Mais la question est pertinente: ce nouveau JavaFX est parfois présenté comme étant un Swing 2.0... dans les faits, cette première release ne devrait être qu'une couche séparée mais avec un degré d'interopérabilité bien supérieur à ce qu'avait l'ex JavaFX et son DSL.

JavaFx a son propre language de script. Et beaucoup de monde, moi y compris, trouve pas ca terrible.

Pourtant un bon DSL qui permette de définir l'interface graphique ainsi que son comportement devrait être un réel plus.

Est-ce l'apprentissage d'un nouveau langage qui rebute le développeur ?

[bouye]

Le premier JavaFX était déjà présenté comme Swing 2.0 par Richard Blair et divers autres intervenants de chez Sun/Oracle.

[Philippe Bastiani]

Le premier JavaFX était déjà présenté comme Swing 2.0 par Richard Blair et divers autres intervenants de chez Sun/Oracle.

ll avait donc dans l'idée de nous faire basculer sur un DSL pour le design d'application... mais pourquoi donc l'interopérabilité Java<>JavaFX était-elle si mal pensée ?
Un DSL quel qu'il soit ne peut être suffisant pour le développement métier... ce n'est pas son rôle !

[bouye]

Comme dit plus haut, ça fait déjà pas mal de temps qu'il ne foutent plus rien sur Swing (bien plus que 7 ans en fait) et comme tout le monde réclamait des nouveautés (sans parler du JWebPane sans arrêt reporté) et des APIs plus modernes il fallait bien donner à manger aux gens.

Pour rappel au début F3 ne devait être rien d'autre qu'un language pour scripter Swing, pas une API à part entière. Ensuite se sont greffés dessus une API warpant les composant Swing et construite sur le scenegraph (initialement créé pour Java2D/Swing) permettant de faire la GUI en script mais avec les classes métier en Java. C'est en interne que ça a fumé peu avant de la sortie de la 1.0 et qu'ils ont décidé de faire que l'API publique, complêtement Script, en supprimant de façon totalement inatendue pas mal de warppers qui fonctionnaient pourtant très bien durant la beta.