Discussion :

[padre.cedano]

Bonjour,

Par curiosité, j'aimerais savoir pourquoi JavaFX dans le Forum est ici java/interfaces-graphiques-java/javafx/ ?

Comme s'il faisait partie des interfaces graphiques telles que Swing et autres.

C'est à présent un langage de programmation n'est-ce pas ?

Merci d'avance pour vos réponses.

[Pill_S]

Non, pas du tout, c'est bien une API de présentation, exactement comme Swing, AWT, SWT...

Si tu penses à JavaFX v1.x (qui effectivement proposait un langage de scripts différent de Java), il est mort et enterré, et c'est d'ailleurs une très bonne chose

[bouye]

En effet et même du temps de JavaFX 1.x, c’était une technologie tournant intégralement sur du Java avec des techno Java (puisque le terme Java concerne a la fois le langage Java, la VM Java, l'API Java, les outils du JDK, etc. etc etc). JavaFX 1.x et JavaFXScript étaient tous deux des technologies Java tournant sur la JVM avec les API Java. Et déjà à l’époque Sun l'avait placé comme étant le successeur et le remplaçant de Swing (ça fait déjà 7 ans que Swing n'a plus eut d’évolutions majeures !).

Par contre la question peut se poser effectivement du besoin de laisser JavaFX... dans le forum Java & Mobiles pour le moment (il y a une redirection vers ici).
Du temps de JavaFX 1.x, l'ambition de Sun était clairement de faire de JavaFX la plateforme d'avenir pour tous les téléphones mobiles ainsi que les JavaTV. Or on sait ce qu'il en est advenu : rien et une grande perte d’énergie.

Pour JavaFX 2 Oracle n'a pas vraiment de plans concernant le mobile (a part trainer Google en justice) soufflant à la fois le chaud (JavaOne 2011 - présentation de JavaFX sur iOS, Android & Windows Mobile) et le froid (JavaOne 2012 - rien) et se contente de vaguement supporter des projets OpenSource visant a permettre l’exécution de Java sur iOS et Android mais ils ne semblent pas vraiment avoir bien choisi comment se positionner d'entre Oracle ADF Mobile (la solution HTML5 d'Oracle pour Mobiles) ou des JVM embarquées. Ils sont cependant plus présents sur Embedded (puisque la c'est Oracle qui fourni directement la VM) mais sans stratégie particulière.

Par contre oui je conçoit que la description du forum pourrait être modifiée puisqu'il n'y a plus de "langage JavaFX" à proprement parler.

[padre.cedano]

Merci, merci.

Je posais la question parce qu'ayant commencé un projet avec Swing, j'ai décidé de le "re-écrire" en JavaFX, je dis re-écrire car j'ai trouvé pas mal de choses qui changent dans l'écriture entre Java et JavaFX.

Par exemple, les noms de composants on les écrit pas dans JavaFX avec la J devant (TextField et non pas JTextField)…

Autre exemple: les bindings (on attend l'article de Bouye ) , est-ce qu'ils marcheraient aussi dans Java…

Autre exemple, les combobox autocomplete très utiles dans mon cas… ils ne marchent pas avec JavaFX.

Et surement d'autres choses.

Voilà pourquoi je me demandais si JavaFX n'avait pas quelque chose de plus qu'une simple interface graphique.

[bouye]

Autre exemple: les bindings (on attend l'article de Bouye ) , est-ce qu'ils marcheraient aussi dans Java…

En théorie oui mais il faut faire attention a ceux qui demandent d'avoir le JavaFX Application Thread de lancé (pas mal des contrôles existant et Service et Task aussi). Cependant pour le reste c'est censé être relativement indépendant.

Autre exemple, les combobox autocomplete très utiles dans mon cas… ils ne marchent pas avec JavaFX.

On peut trouver des prototypes et avec les FilteredObservableList du JDK8 ça doit être encore plus simple a faire. je crois que j'ai un code qq part qui fait ca, je fouillerai.

Voilà pourquoi je me demandais si JavaFX n'était quelque chose de plus qu'une simple interface graphique.

C'est vrai mais dans le même style Java2D et tout ce qui est event listener de base ou les BeansProperties n'est pas vraiment lie non-plus a une UI dans leur implémentation publique (en prive cependant certaines classes nécessitent d'avoir EDT qui tourne ou que l'applicatione soit pas lance en mode headless car dependant du gestionnaire d'ecran alors que l'API publique laisserait a penser que non). Dans le même style le package d'impression, javax.print, a une dépendance a Swing et plantait sur MacOS dans JDK7 (pas teste avec JDK8) car une app JavaFX pure s'y lance en mode headless.