JavaFX 1.2.3 dispo

bouye · 07/02/2010, 22h21

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 · 08/02/2010, 08h18

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 · 08/02/2010, 08h30

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 · 08/02/2010, 10h09

Citation:

Envoyé par Obligen

.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.1486 · 08/02/2010, 11h05

Citation:

Envoyé par pseudocode

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 · 08/02/2010, 15h14

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 !

arno31 · 08/02/2010, 15h31

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 · 08/02/2010, 22h19

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.

bouye · 08/02/2010, 22h21

Citation:

Envoyé par 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 !

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 !.

Obligen · 09/02/2010, 08h54

Le langage de script est sympa mais a aussi ses lacunes, et ce dans les deux aspects suivants :

Couche applicative : je trouve le javafx script très agréable à utiliser, notamment pour la manipulation de tableaux et de chaines. On se rapproche fortement de python/ruby et ce n'est pas désagréable. Toutefois, quel est le coût en performances? Maintenant que Java pur est super bien optimisé, ce serait dommage de reprendre la polémique "code managé carrément plus lent que code natif"...

Couche graphique : là, c'est sympa car cela permet de concevoir les interfaces plus simplement qu'en code pur, mais le modèle a un très sérieux plomb dans l'aile je trouve. Il tente de se rapprocher du modèle de Microsoft (WPF) avec du C# pour le code et du XAML pour l'interface, mais avec beaucoup plus de lourdeurs ! En effet, une interface XAML peut être très complexe mais rester lisible, car un chouilla condensée. En Javafx, mettre chaque attribut sur une ligne, et imbriquer les blocs les uns dans les autres quasi à l'infini, rendent l'interface presque impossible à lire ! C'est un bordel monstrueux ! Et ce même dans les exemples officiels de Sun, il suffit qu'il y ait autre chose qu'un simple texte dans un rectangle pour que le fichier d'interface soit illisible !

De plus, concernant la couche graphique, autant en WPF tout se redimensionne très facilement quand on redimensionne la fenetre (les composants prennent tout l'espace disponible si on ne précise pas de dimensions), autant en JavaFX les composants ont une taille fixée, et c'est extrêmement lourd ! On est en 2010, finies les descriptions d'interfaces au pixel près !! caykoicebordel ? Si JavaFX a décidé de faire une croix sur les applications desktop (du moins leur simplicité de conception), il se tire une balle dans le pied !

Bref, il reste du boulot. J'adore Java, le concept d'application multi-plateformes est très séduisant, mais il y en a certaines que je développe forcément en WPF histoire d'avoir le confort du développement, même si je perd en interopérabilité...

Traroth2 · 09/02/2010, 17h13

Citation:

Envoyé par bouye

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 !.

Oui, ça date peut-être de F3, ça. Mais le problème de not, and et or est similaire. Faire différent juste pour faire différent, c'est idiot. C'est pas grave, mais on ne peut pas s'empêcher de se demander à quoi pensaient les mecs qui ont fait ça...

J'ai été enthousiasmé par l'annonce de JavaFX, puis, quand il est arrivé, j'ai été extrêmement déçu, et je m'en suis rapidement désintéressé, je dois le dire.

Vous avez remarqué qu'Amazon.com annonce un bouquin sur JavaFX 2 (chez APress) depuis 2 mois ? En décembre,
il était prévu pour le 4 janvier, puis le 11, et aux dernières nouvelles, pour le 12 mars...

Amazon.com: Pro JavaFX 2 Platform: A Definitive Guide to Script, Desktop, and Mobile RIA with Java Technology (9781430268727): James L. Weaver, Stephen Chin, Weiqi Gao, Dean Iverson: Books
Amazon.com: Pro JavaFX 2 Platform: A Definitive Guide to Script, Desktop, and Mobile RIA with Java Technology (9781430268727): James L. Weaver, Stephen Chin, Weiqi Gao, Dean Iverson: Books

Personnellement, je n'attends rien de particulier, de JavaFX 2. Il n'est jamais vraiment trop tard pour une vraiment bonne technologie, mais je pense que si JavaFX avait dû être une bonne techno, ça serait déjà fait. Avec le rachat par Oracle, je ne donne pas cher de la peau de JavaFX dans un avenir assez proche, personnellement. La techno rejoindra le club des technos dérivées de Java qui vivotent plus ou moins, avec JXTA, Jini et les autres...

bouye · 09/02/2010, 22h31

Houlala

... ca me fait peur sur le coup ! J'imagine deja les petits genies qui servent de commerciaux chez Sun nous pondre un coup a la Java SE 2 (1.2)... JavaFX 2 (1.3) ????

Apres tout ces pauvres gens n'ont rien a se mettre sous la dent ces derniers temps depuis leur dernier fait d'arme vu le retard pris par Java 7 :

Java (1.0) -> Java 1.1 -> Java SE 2 (1.2) -> Java 1.3 et 1.4 -> Java 5.0 (1.5) -> Java 6 (1.6) -> JDK 7 (1.7)

galien · 14/02/2010, 04h51

Et bien, vous êtes bien critique avec javaFX, un peu tirer sur une ambulance...
Quand à franchement pinailler sur les not <> et consort ca ne fait pas de mal de passer d'un langage à l'autre.
On peut dire que le runtime commence à réaliser ses promesses, le retard sur les composants est assez irritant quand on est flemmard et qu'on attends une api pour faire un bouton.
D'autre part la synthaxe c'est aussi un question de design pour que le code soit lisible

Citation:

'interface presque impossible à lire ! C'est un bordel monstrueux

C'est peu être un peu subjectif! Quand on pense a la génese du language, F3, et à l'esprit de son concepteur ce langage est aussi une tuerie côté graphisme pur, voir le blog de Chris Oliver. Les closures associés au binding sont vraiment intéressantes.
Contrairement à ceux qui pensent que c'est une technologie morte née, je crois plutôt qu'elle arrive au bon moment. On assiste à une bataille rangée autour d'HTML 5 et javaFX pourrait y tirer son epingle du jeux. Alors que sl et flash repose sur une execution isolée au conteneur( en HTML) javaFX pourrait facilement interagir avec l'écosystème HTML, l'arbre dom, le code javascript. C'est ce que semble annoncer oracle dans sa dernière keynote.
Quels seront les rapports de force entre Google, Apple, Oracle, Mircrosoft ou Adobe sur le HTML5, aucune idée mais que javaFX fasse le pari de RIAiser le HTML5 me parait pas idiot.

pseudocode · 14/02/2010, 13h21

Citation:

Envoyé par galien

Contrairement à ceux qui pensent que c'est une technologie morte née, je crois plutôt qu'elle arrive au bon moment. On assiste à une bataille rangée autour d'HTML 5 et javaFX pourrait y tirer son epingle du jeux. Alors que sl et flash repose sur une execution isolée au conteneur( en HTML) javaFX pourrait facilement interagir avec l'écosystème HTML, l'arbre dom, le code javascript. C'est ce que semble annoncer oracle dans sa dernière keynote.
Quels seront les rapports de force entre Google, Apple, Oracle, Mircrosoft ou Adobe sur le HTML5, aucune idée mais que javaFX fasse le pari de RIAiser le HTML5 me parait pas idiot.

Il va falloir faire un gros effort pour rendre JavaFx accessible à monsieur et madame tout-le-monde.

------------------------------------------------------------------------------------

3615 mylife : je teste JavaFx, par pseudocode.

1. JavaFx n'étant pré-installé par aucun browser, il faut le faire soit meme --> google javafx --> javafx.com --> download now

choix possibles pour le téléchargement:

NetBeans IDE 6.8 for JavaFX 1.2
JavaFX 1.2 Production Suite
JavaFX 1.2.3 SDK
JavaFX Mobile 1.2 for Windows Mobile

(Bon courage a ceux qui prennent la première proposition)

2. Allez, bon prince, je prend le SDK : 50Mo de download (pour rappel : silverlight=5Mo et flash=2Mo). Je lance l'installation.

--> JDK 6u18+ not found : require download

et allez, 76Mo de plus a télécharger. Bon, ca se fait tout seul.

Lancement automatique du setup de Java SE
2.1 écran pour accepter la licence
2.2 écran pour choisir les fonctionalités (tools, demos/samples, source, public jre). Là je pense que Mme michu elle est perdue, mais bon, je continue en cliquant sur NEXT (Full install = 300 Mo !!!!!)
2.3 écran pour choisir l'emplacement du jre public

(là j'en suis déjà a 5 minutes depuis ma recherche google, et j'ai une bonne connexion ADSL et un bon PC)

2.4 écran "fin d'installation de Java"
2.5 Ouverture de mon browser sur la page "register" du Java Development Kit
2.6 Erreur windows : Runtime Error Microsoft Visual C++

--> pas grave, je clique sur Ok.

2.7 Ecran installation de JavaFx
2.8 écran pour choisir l'emplacement

(ca s'installe)

2.9 Ouverture de mon browser sur la page "register" du Java FX SDK
2.10 Popup de Warning : avertissement de sécurité lié a HTTPS --> pas grave, je clique sur oui.
2.11 écran "fin d'installation de Java FX"

Yeeahhhhhhhhhh !!!

Bon, aucune idée si ca a marché ou pas -> Retournons sur javafx.com

-> apparition de l'icone Java dans la zone de notification de windows
-> Info bulle : Venez nous rendre visite sur Java.com (rappel : j'ai déja 2 fenetres "register" ouvertes)
-> Fenetre de confirmation sur mon browser : "Support et contenu de qualité Java Fx" bla bla bla --> je clique sur accepter

OOOOUUUUI ! OOOOUUUUI !

10+ minutes et 400Mo de fichiers plus tard, j'ai enfin du texte et 4 images qui s'affichent dans la zone bleue en pas de ma page Web

(je passe sur l'auto-update mensuel de java qui est maintenant configuré par défaut sur mon PC)

------------------------------------------------------------------------------------

Non, y a pas à dire, va falloir faire un effort.

herch · 14/02/2010, 17h05

Le SDK est pour les développeurs.

Monsieur et Madame tout le monde ont seulement besoin du runtime, qui est installé automatiquement lorsqu'un programme JavaFX est exécuté. Il faut simplement avoir une JRE 5 et plus (pas besoin du JDK).

La taille du runtime (java et non JavaFX) est:

Windows (installation en ligne) : 10 Mo
Windows (installation hors ligne) : 19 Mo
Linux : 19 Mo

http://www.java.com/fr/download/manual.jsp

Je me demande vraiment d'où est-ce que tu as sorti tous ces chiffres astronomiques?

Et puis à ce que je sache, Silverlight requiert le framework .NET (qui est loin des 5 Mo), et plus important, Windows

. Etant un utilisateur de Linux, je n'ai jamais eu le plaisir de voir une application Silverlight tourner en utilisant Moonlight.

Et puis il faut pas oublier que JavaFX est sorti il y a à peu près deux ans, donc il faudra lui donner un peu de temps.

07/02/2010, 22h21	#1 (permalink)
bouye Modérateur Date d'inscription: août 2005 Localisation: Nouméa, Nouvelle-Calédonie Âge: 33 Messages: 3 155	JavaFX 1.2.3 dispo 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 __________________ Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes. Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

08/02/2010, 15h14	#6 (permalink)
Traroth2 Membre éprouvé Date d'inscription: décembre 2003 Messages: 460	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 ! __________________ Traroth http://traroth.labrute.fr

08/02/2010, 22h19	#8 (permalink)
bouye Modérateur Date d'inscription: août 2005 Localisation: Nouméa, Nouvelle-Calédonie Âge: 33 Messages: 3 155	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. __________________ Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes. Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

09/02/2010, 08h54	#10 (permalink)
Obligen Nouveau membre du Club Date d'inscription: décembre 2006 Localisation: Bordeaux o.o/ Âge: 24 Messages: 58	Le langage de script est sympa mais a aussi ses lacunes, et ce dans les deux aspects suivants : Couche applicative : je trouve le javafx script très agréable à utiliser, notamment pour la manipulation de tableaux et de chaines. On se rapproche fortement de python/ruby et ce n'est pas désagréable. Toutefois, quel est le coût en performances? Maintenant que Java pur est super bien optimisé, ce serait dommage de reprendre la polémique "code managé carrément plus lent que code natif"... Couche graphique : là, c'est sympa car cela permet de concevoir les interfaces plus simplement qu'en code pur, mais le modèle a un très sérieux plomb dans l'aile je trouve. Il tente de se rapprocher du modèle de Microsoft (WPF) avec du C# pour le code et du XAML pour l'interface, mais avec beaucoup plus de lourdeurs ! En effet, une interface XAML peut être très complexe mais rester lisible, car un chouilla condensée. En Javafx, mettre chaque attribut sur une ligne, et imbriquer les blocs les uns dans les autres quasi à l'infini, rendent l'interface presque impossible à lire ! C'est un bordel monstrueux ! Et ce même dans les exemples officiels de Sun, il suffit qu'il y ait autre chose qu'un simple texte dans un rectangle pour que le fichier d'interface soit illisible ! De plus, concernant la couche graphique, autant en WPF tout se redimensionne très facilement quand on redimensionne la fenetre (les composants prennent tout l'espace disponible si on ne précise pas de dimensions), autant en JavaFX les composants ont une taille fixée, et c'est extrêmement lourd ! On est en 2010, finies les descriptions d'interfaces au pixel près !! caykoicebordel ? Si JavaFX a décidé de faire une croix sur les applications desktop (du moins leur simplicité de conception), il se tire une balle dans le pied ! Bref, il reste du boulot. J'adore Java, le concept d'application multi-plateformes est très séduisant, mais il y en a certaines que je développe forcément en WPF histoire d'avoir le confort du développement, même si je perd en interopérabilité...

09/02/2010, 22h31	#12 (permalink)
bouye Modérateur Date d'inscription: août 2005 Localisation: Nouméa, Nouvelle-Calédonie Âge: 33 Messages: 3 155	Houlala... ca me fait peur sur le coup ! J'imagine deja les petits genies qui servent de commerciaux chez Sun nous pondre un coup a la Java SE 2 (1.2)... JavaFX 2 (1.3) ???? Apres tout ces pauvres gens n'ont rien a se mettre sous la dent ces derniers temps depuis leur dernier fait d'arme vu le retard pris par Java 7 : Java (1.0) -> Java 1.1 -> Java SE 2 (1.2) -> Java 1.3 et 1.4 -> Java 5.0 (1.5) -> Java 6 (1.6) -> JDK 7 (1.7) __________________ Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes. Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

08/02/2010, 08h18	#2 (permalink)
Obligen Nouveau membre du Club Date d'inscription: décembre 2006 Localisation: Bordeaux o.o/ Âge: 24 Messages: 58	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

08/02/2010, 08h30	#3 (permalink)
Lorantus Membre éclairé Date d'inscription: août 2007 Localisation: Annecy Âge: 38 Messages: 383	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...

08/02/2010, 15h31	#7 (permalink)
arno31 Membre du Club Date d'inscription: octobre 2007 Localisation: Toulouse Âge: 27 Messages: 80	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.

14/02/2010, 17h05	#15 (permalink)
herch Membre chevronné Date d'inscription: mai 2006 Âge: 24 Messages: 648	Le SDK est pour les développeurs. Monsieur et Madame tout le monde ont seulement besoin du runtime, qui est installé automatiquement lorsqu'un programme JavaFX est exécuté. Il faut simplement avoir une JRE 5 et plus (pas besoin du JDK). La taille du runtime (java et non JavaFX) est: Windows (installation en ligne) : 10 Mo Windows (installation hors ligne) : 19 Mo Linux : 19 Mo http://www.java.com/fr/download/manual.jsp Je me demande vraiment d'où est-ce que tu as sorti tous ces chiffres astronomiques? Et puis à ce que je sache, Silverlight requiert le framework .NET (qui est loin des 5 Mo), et plus important, Windows . Etant un utilisateur de Linux, je n'ai jamais eu le plaisir de voir une application Silverlight tourner en utilisant Moonlight. Et puis il faut pas oublier que JavaFX est sorti il y a à peu près deux ans, donc il faudra lui donner un peu de temps. __________________ En essayant continuellement on finit par réussir. Donc : plus ça rate, plus on a de chances que ça marche.

		Forum des professionnels en informatique > Java > Interfaces Graphiques en Java > JavaFX
JavaFX 1.2.3 dispo

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email