Un développeur lance une pétition pour que JavaFX soit open-sourcé, allez-vous la signer ?

JavaFX devient « JFX » et open-source
Oracle propose formellement la technologie à l'OpenJDK

Mise à jour du 3 novembre 2011 par Idelways


Oracle tient sa promesse engagée en marge de la dernière conférence JavaOne. JavaFX est aujourd'hui formellement proposé à devenir open source dans le cadre du projet OpenJDK.

Le Toolkit de développement d'applications client riches en Java s'appellera « JFX » et pourrait faire « partie intégrante du JDK » dès Java 9, déclare Richard Bair sur la mailing-list de la version libre du langage.

« Nous en avons parlé depuis longtemps, mais finalement (enfin !), nous sommes prêts à agir et ouvrir les sources de la plateforme », déclare le porte-parole de l'équipe JavaFX, pressenti pour conduire le projet open source. Bair explique par la suite que la réelle motivation de cette démarche est d'aboutir à un modèle de développement ouvert et transparent.

Le code ainsi offert représente 6000 membres d'API (constructeurs, méthodes publiques...), 11 500 tests unitaires, des librairies Core, Scene Graph, effets, support du CSS et de l'accélération matérielle, des contrôles d'interface utilisateur et de graphes...

Le vote aura lieu le 16 novembre prochain. Les composants de la technologie seront libérés progressivement à commencer par les contrôles. À terme, OpenJFX ne dépendra plus de binaires.

La licence open source qui signera le code n'est pas encore connue (ou dévoilée). La GPLv2 avec l'exception Classpath reste toutefois le choix le plus probable.



Source : mailing-list d'OpenJDK

Et vous ?

:fleche: Que pensez-vous de cette démarche ?
:fleche: Quelles sont d'après vous ses réelles motivations, et retombées sur l'écosystème Java ?




Un développeur lance une pétition pour que JavaFX soit open-sourcé, allez-vous la signer ?

Stephen Chin est un passionné de développement open-source et de Java en particulier, qu'il pratique depuis plus de 10 ans sur son temps libre (il est directeur de l'ingénierie SW chez GXS la journée). Membre très actif de la communauté, il a été élu membre du groupe Java Champions du fait de ses nombreuses contributions.

L'homme est aussi le fondateur du groupe d'utilisateurs de JavaFX de la Silicon Valley et a été nommé JavaOne Rock Star en 2009 (du fait de ses interventions internationales à propos des technologies JavaFX).

Très impliqué à ce sujet, il était logique qu'il soit l'instigateur de la pétition demandant l'ouverture de JavaFX. En effet, sur son blog, celui qu'on appelle "Steve" a lancé une pétition s'adressant aux dirigeants d'Oracle et demandant à ce que JavaFX soit open-sourcé. Elle a déjà reçu des centaines de signatures.

En voici le texte intégral :

Citation:

---

To the Leaders, Management, and Board of Directors at Oracle Corporation,

We the undersigned formally request that Oracle Corporation release the entire JavaFX Platform as open source software available for modification and reuse by individuals, educators, and corporations.

Open source software has transformed the way that we build and use software. It has increased the educational reach of technology, allowed new and innovative applications to emerge, and spawned the growth of communities dedicated to software philanthropy. Java has been at the forefront of this revolution, providing a platform for open source development, and becoming an open source effort in itself.

JavaFX is an innovative technology built on top of Java that allows the creation of next generation Rich Internet Applications (RIA). We believe that an essential part of the future success of this platform is to release it as open source software. This would increase adoption by companies that fear lock-in or are concerned about technology maturity. It would also make it competitive with other RIA platforms that have embraced the open source model.

We recognize that Oracle Corporation has made a significant investment in JavaFX technology, and continues to grow and extend the platform. We encourage Oracle to continue their investment in the JavaFX platform, including monetization of the platform through training, support, and other professional services. In our estimation, the increased adoption of JavaFX will make the platform even more profitable for Oracle than it currently is as a proprietary technology.

Therefore, we proudly make this request to open source the JavaFX platform in the mutual interest of JavaFX technology and the future success of Oracle Corporation.

---

Source : La pétition sur le site de Stephen Chin

:fleche: Allez-vous signer ? Pourquoi ?

Open-sourcé ou pas, je ne pense pas que ca changera quoi que ce soit pour la popularité de JavaFx.

A mon sens, SUN a manqué son attaque sur ce marché en voulant absolument réutiliser sa sacro-sainte plateforme JSE (jvm+rt.jar) au lieu de concevoir une VM dédiée "allégée". dommage...

Citation:

---

SUN a manqué son attaque sur ce marché en voulant absolument réutiliser sa sacro-sainte plateforme JSE (jvm+rt.jar) au lieu de concevoir une VM dédiée "allégée". dommage...

---

C'est vrai mais comment faire autrement si l'on veut pouvoir utiliser les packages java natif ? 8O

Citation:

---

Envoyé par salve34

C'est vrai mais comment faire autrement si l'on veut pouvoir utiliser les packages java natif ? 8O

---

Si "on" veut utiliser l'environnement JSE dans un browser web il y a déjà une techno : les applets java.

D'après ce que j'ai compris JavaFx attaquait le marché de flash/silverlight, c'est à dire, en gros, celui des animations 2D, de l'audio/vidéo et de l'interaction Homme/Machine. Bref autant de chose qui manquent cruellement a JSE, au point qu'il a fallu créer un langage/libraire spécifique. Donc en fait, pas besoin de JSE.

Et puis, technologiquement, il était toujours possible de garantir l'interopérabilité entre les plateformes JavaFx et JSE.

J'aurais préféré une "JVM allégé" pour JavaFX, installable en quelques secondes sur un browser, et dédiée au fonctionnalités web. Rien que pour la communauté open-source, ca aurait été mieux de pouvoir maintenir/porter le pack complet "jvm-fx + langage java-fx".

Citation:

---

Envoyé par pseudocode

A mon sens, SUN a manqué son attaque sur ce marché en voulant absolument réutiliser sa sacro-sainte plateforme JSE (jvm+rt.jar) au lieu de concevoir une VM dédiée "allégée". dommage..

---

Moi ce qui m'a rebuté à utiliser javaFx, c'est qu'il était impossible de faire une application avec une belle interface javafx et un beau code bien propre en java standard derrière, impossible de lier tout correctement. On pouvait très facilement faire de belles interfaces bien réactive en 2 coupsde cuiller à pot, mais impossible de lier ça au code buisness déjà développé!

Citation:

---

Si "on" veut utiliser l'environnement JSE dans un browser web il y a déjà une techno : les applets java.

---

Désolé je comprends pas ce que tu veux dire.
Pour ma part je voulais dire que JavaFX embarque la même JVM pour assurer une compatibilité avec Java (Swing par exemple) mais c'est vrai que l'on peut faire sans. Moi je crois en JavaFX (qui est gratuit, multi-plateforme et multi-technologie => portable, télé ) mais je le redis, je suis d'accord qu'une JVM allégée aurait été mieux. Bon j'arrête là car ce n'est pas le sujet du post :zoubi:.

Je ne crois pas me tromper en disant que pour une JVM allégée c'est déjà la cas.
En effet le runtime javaFX, de 8Mo environ, distribué avec le SDK ou via Webstart est un sous ensemble de la JRE.
La grande nouveauté sera avec java7 et son micro noyau pour le chargement à la volée.
L'avantage de javaFX reste néanmoins son mapping avec openGL, déjà présent pour la 2D et expérimentalement pour la 3D, incompatible avec Swing, en ce sens javaFX n'est pas à la "traine".
Reste la politique d'Oracle et les préjugés lourds à propos de javaFX, tels les commentaires laissant penser que de leurs auteurs ne l'ont pas essayé avant d'en parler.
Plus que l'Opensourcing je pense que javaFX pourrait aquerir ses lettres de noblesses avec un OpenOffice version Web en javaFX.

Citation:

---

En effet le runtime javaFX, de 8Mo environ, distribué avec le SDK

---

Si l'on est en Internet pas en Intranet non ?:roll:

Citation:

---

incompatible avec Swing

---

la version 1.2 ????

Citation:

---

tels les commentaires laissant penser que de leurs auteurs ne l'ont pas essayé avant d'en parler

---

C'est pour nous que tu dis çà ? car ce n'est pas le cas ( mais je ne suis pas un expert bien au contraire :oops:)

Citation:

---

Plus que l'Opensourcing je pense que javaFX pourrait aquerir ses lettres de noblesses avec un OpenOffice version Web en javaFX.

---

Tout à fait d'accord mais c'est sur les techno portables et télés que je pense qu'il percera

Citation:

---

Envoyé par galien

Je ne crois pas me tromper en disant que pour une JVM allégée c'est déjà la cas.
En effet le runtime javaFX, de 8Mo environ, distribué avec le SDK ou via Webstart est un sous ensemble de la JRE.
La grande nouveauté sera avec java7 et son micro noyau pour le chargement à la volée.

---

Ce n'est pas vraiment une JVM dédiée allégée. C'est la JVM "standard" qui a été modularisée... Et donc la question qui se pose : pourquoi a-t-elle été modularisée ?

Et bien parce que charger le quelques 90Mo du JRE standard ça paraissait un peu énorme pour une utilisation de javaFx qui se veut légère, à la flash/silverlight. Bref, plutot que de créer une techno dédiée from scratch, ils ont préféré mettre en oeuvre un énorme chantier de modularisation de la JVM.

Et idem pour le chargement dynamique des librairies (rt.jar = 47Mo). C'est un boulot énorme qui ne sert pratiquement que dans le cas de JavaFx. Dans une appli JSE classique l'utilisateur dispose de l'intégralité du JRE sur sa machine (et ne veut certainement pas que du code soit chargé dynamiquement depuis dieu-sait-où sur le web)

J'ai du mal à voir l'avantage de la chose. Ça aurait été tellement plus simple de séparer les deux technos :
- JavaFx : jvm+librairie "light", from scratch, gérée par un comité dédié, très réactif
- JSE : jvm+librairie standard, basée sur le jdk7, gérée par le JCP, très controlé

Aujourd'hui, si on veut faire une évolution de JavaFx qui touche au fonctionnement interne de la JVM/Rt.jar, on est bloqué car on touche au même code que JSE => passage par le JCP avec des cycles de release trèèèès long.

Exemple typique : avoir une JVM qui fasse de l'allocation dynamique de mémoire, ou qui soit multi-application, ... bref des choses assez naturelles quand on parle de "web".

@Slave34
Le déploiement doit se faire via jnlp, le runtime doit être spécifié par une entrée ressource du jnlp.
Pour un intranet la licence autorise de faire une copie des runtimes et de les rendre disponibles via http sur cet intranet.
Autrement ils sont téléchargés de dl.javafx.com. Ceci dit une fois chargé le runtime est mis en cache sur la machine et n'a pas besoin d'être re-téléchargé.

La compatibilité avec Swing est temporairement conservée avec la 1.3, le problème se situant au niveau de l'accélération hardware du stack graphique de javaFX (basé sur JOGL). L'utilisation de Swing provoque des changements de contexte au niveau du SceneGraph (j2D/JOGL) ce qui est très pénalisant pour les performances. En tout état de cause, utiliser Swing avec javaFX est un peu un non sens, le paradigme programmatique étant complètement différent. Mais cela a permis à beaucoup de pallier les manques de l'API au début.
A noté que l'on peut pas utiliser Swing et la 3D en mode expérimental.

Sur sa future adoption sur les plateformes "entertainenment", pourquoi pas, les performances du stack graphique par rapport aux autres peuvent laisser y songer.(Rappelons que Flash vient à peine de supporter l'accélération 2D).
Cependant je vois bien javaFX s'implémenter dans les entreprises, la politique de sécurité étant un atout pour javaFX qui l'intègre nativement.

Citation:

---

Envoyé par galien

Je ne crois pas me tromper en disant que pour une JVM allégée c'est déjà la cas.
En effet le runtime javaFX, de 8Mo environ, distribué avec le SDK ou via Webstart est un sous ensemble de la JRE.
La grande nouveauté sera avec java7 et son micro noyau pour le chargement à la volée.
L'avantage de javaFX reste néanmoins son mapping avec openGL, déjà présent pour la 2D et expérimentalement pour la 3D, incompatible avec Swing, en ce sens javaFX n'est pas à la "traine".

---

Je ne pense pas que ça soit le 3D qui est intéressante dans se genre de techno mais les possibilités d'avoir des composant facilement adaptable. je le vois bien avec Silverlight, faire une application un peu classe sur une application métier c'est devenu une réaliser, alors qu'avant on avait une vielles Datagrid avec un look windows 98 dans le meilleur des cas, maintenant on a une belle IHM avec des composants sympa (style datagrid avec ImageBox, DateTimePicker etc... ) et ça demande pas plus de travail que ça.

parce que franchement la 3D pour le moment c'est que dans les jeux et les démo technique...

Citation:

---

Envoyé par galien

Reste la politique d'Oracle et les préjugés lourds à propos de javaFX, tels les commentaires laissant penser que de leurs auteurs ne l'ont pas essayé avant d'en parler.
Plus que l'Opensourcing je pense que javaFX pourrait acquerir ses lettres de noblesses avec un OpenOffice version Web en javaFX.

---

Bof, Silverlight n'as pas attendu un Office pour avoir ses lettres de noblesse. Il y a juste du concret a grand renfort de conférence et de présentation en grande pompe.

alors que JavaFX, ça n'avance pratiquement pas depuis 2 ans... en plus d'un silence radio...
d'où, sans doute, la demande de passé en open source.

Citation:

---

Et idem pour le chargement dynamique des librairies (rt.jar = 47Mo). C'est un boulot énorme qui ne sert pratiquement que dans le cas de JavaFx.

---

Je crois que cette problématique a été abordée avant JavaFX, l'un des avantages de la modularité étant la gestion des versions des modules, ou le fait de pouvoir faire tourner plusieurs versions d'une API dans un même application, un peu comme avec une plateforme OSGI.

Citation:

---

J'ai du mal à voir l'avantage de la chose. Ça aurait été tellement plus simple de séparer les deux technos :
- JavaFx : jvm+librairie "light", from scratch, gérée par un comité dédié, très réactif
- JSE : jvm+librairie standard, basée sur le jdk7, gérée par le JCP, très controlé

---

C'est aussi favoriser l'éclatement de la plateforme, ce qui conduit à des impasses et un casse tête pour maintenir une unification, voir J2ME et sa fragmentation, je crois que chez Sun il n'ont pas voulu recommencer l'expérience d'une JVM dédiée pour chaque implémentation hardware.
A quoi bon refaire un runtime Flash?

De plus je crois que tu mélanges l'API JRE et l'API javaFX qui sont séparées (pas la même licence d'ailleurs) et avec du côté javaFX avec les profils desktop, mobile et TV.

Je ne crois pas que JavaFX ne soit soumis en rien au JCP, (à part le JSR sur les langages dynamiques et donc la partie java-> javaFX).

Citation:

---

Bof, Silverlight n'as pas attendu un Office pour avoir ses lettres de noblesse. Il y a juste du concret a grand renfort de conférence et de présentation en grande pompe.

alors que JavaFX, sa n'avance pratiquement pas depuis 2 ans... en plus d'un silence radio...
d'où, sans doute, la demande de passé en open source.

---

Des lettres de noblesse pour Silverlight? J'en ai vu un seul gros exemple avec le site de France télévision, et on peut pas franchement parler de succès...heureusement qu'il reste Youtube.
JavaFX n'avance pas depuis deux ans?
Pour rappel:
Version 1 interprétée, reprise de F3.
Version 2 compilé basée sur java2D
Version 3 Stack 2D/3D graphique basé sur PRISM + CSS.

Ce n'est pas ce que j'appelle ne rien faire.
Je persiste et signe, ils n'ont pas rien fait, les personnes qui ont développé avec javaFX depuis tout ce temps le savent, qui plus est quand on considère le contexte du rachat par Oracle et la désorganisation qui s'en suit.

Citation:

---

Envoyé par galien

C'est aussi favoriser l'éclatement de la plateforme, ce qui conduit à des impasses et un casse tête pour maintenir une unification, voir J2ME et sa fragmentation, je crois que chez Sun il n'ont pas voulu recommencer l'expérience d'une JVM dédiée pour chaque implémentation hardware.
A quoi bon refaire un runtime Flash?

---

J'ai du mal à croire en une techno universelle qui serve aussi bien à afficher un bandeau de pub web, à faire tourner une application bureautique et à gérer un site internet à forte charge. :P

Faut bien se rendre à l'évidence que JSP n'est pas un succès colossal, et que JavaFx l'est encore moins. Je suis le premier à le regretter, mais force est de constater que les technos dédiées s'en sortent beaucoup mieux que les "universalistes".

Citation:

---

De plus je crois que tu mélanges l'API JRE et l'API javaFX qui sont séparées (pas la même licence d'ailleurs) et avec du côté javaFX avec les profils desktop, mobile et TV.

---

Tu veux dire l'API JSE ? Oui, c'est bien possible que je confonde les deux. dans me derniers essais avec JavaFx, celui-ci était livré avec une version allégée de rt.jar. Donc tout de meme une imbrication forte entre les 2 API

Citation:

---

Faut bien se rendre à l'évidence que JSP n'est pas un succès colossal, et que JavaFx l'est encore moins. Je suis le premier à le regretter, mais force est de constater que les technos dédiées s'en sortent beaucoup mieux que les "universalistes".

---

D'accord avec toi, c'est pour cela que javaFX semble plus adapté au RIA d'entreprise qu'a des bannières de pub.

Enfin, concernant le runtime, le compilateur javaFX ne fait que générer des pré-compilés java bourrés d'annotations ;). Considérant javaFX comme une 'sur-couche' de java, je vois pas où est la polémique avec le runtime, il contient le minimum syndical mais peut être complété à souhait, toujours via WebStart.

Citation:

---

Envoyé par galien

D'accord avec toi, c'est pour cela que javaFX semble plus adapté au RIA d'entreprise qu'a des bannières de pub.

---

Quand je parlais de lettre de noblesse pour Silverlight, c'est bien dans ce domaine...
De toute façon que ça soit Silverlight ou JavaFX, je vois mal comment il pourrait concurrencer Flash et l'HTML 5 en terme de bannière et autre vidéo...

et dans le RIA y'a Silverlight mais aussi Flex, et là désolé mais JavaFX est malheureusement à l'arrêt complet par rapport à ses 2 techno. Du moins c'est l'impression que j'ai.

Pourquoi ne pas avoir fait évoluer les applets plutôt que de créer javaFX ? j'ai testé javaFX et ....:cry:

Je préfère carrement utiliser la lib pulpcore pour faire de telles interfaces que javaFX ...

Techniquement, Flash fait plutôt bien son travail dans le domaine du RIA. Pour que JavaFX puisse se faire une place, il aurait été effectivement nécessaire de le placer en open-source, comme Sun s'était engagé à le faire en 2007. Avec Oracle aux commandes, je doute sérieusement que ça arrive, et je ne suis d'ailleurs pas sûr qu'il soit encore temps.

L'appui de la communauté open-source peut être décisif pour la réussite d'un produit ou d'une technologie, et ce ne sont pas les exemples qui manquent. Que se serait-il passé si Sun avait lancé JavaFX sous licence GPL, avec immédiatement un support pour Linux (et pas plusieurs mois après), support des formats audios et vidéos Ogg Vorbis et Theora et une Productive Suite permettant les mêmes fonctionnalités pour Gimp et Inkscape que pour Photoshop et Illustrator ? Nous ne le saurons jamais, et ça laisse comme un goût amer...

Peut-être que les prochaines versions supporteront WebM, puisque Oracle a annoncé qu'il apportait son soutien à ce format. Ça lèverait l'un des principaux obstacles à une publication du code, d'après ce que disait un ingénieur de Sun lors d'une conférence où j'avais posé la question...

En tout cas, j'ai signé la pétition, personnellement.

Citation:

---

Envoyé par Traroth2

L'appui de la communauté open-source peut être décisif pour la réussite d'un produit ou d'une technologie, et ce ne sont pas les exemples qui manquent.

---

Je suis pas forcément convaincu.
y'a aussi le risque de se retrouver avec 15 nouveau framework tous incompatible dont 12 seront abandonnées dans les 4 années qui suivent... et après Oracle arrive avec son JavaFX et dira "C'est un standard !"...

Citation:

---

Je suis pas forcément convaincu.
y'a aussi le risque de se retrouver avec 15 nouveau framework tous incompatible dont 12 seront abandonnées dans les 4 années qui suivent... et après Oracle arrive avec son JavaFX et dira "C'est un standard !"...

---

D'accord avec ça, mettre une techno trop jeune en opensource est dangereux, surtout quand les spécifications ne sont pas encore définitives.
Néanmoins le compilateur javaFX est opensource.

Publish early, publish often...

Personnellement, je crois réellement au logiciel libre, et quand je publie du code, c'est pour avoir un retour de la communauté qui va améliorer le logiciel dans des directions auxquelles je n'aurais peut-être même pas pensé. Publier le code juste parce que c'est la mode, mais sans s'intéresser au feedback de la communauté, quel intérêt ? Si je veux faire ma tambouille sans que personne n'intervienne, je ne vois pas pourquoi je publierais le code.

En l'occurrence, si 15 frameworks étaient vraiment sortis pour JavaFX, c'est la meilleure chose qui aurait pu arriver. Un tel foisonnement aurait été 100% positif, même incompatibles entre eux, et même si 12 s'étaient éteints au bout de 4 ans. Parce que dans les faits, il faut constater que c'est plutôt le calme plat de la mort clinique, du côté de JavaFX...

Bon, on va faire simple : le passage en OpenSource est une fausse bonne idée mise en avant pour de mauvaises raisons, cela peut aider, cela ne changera pas grand chose.
Les principaux problèmes de FX sont :

- un mauvais positionnement : Sun a décidé de se positionner sur tous les marchés à la fois, le desktop ("FX c'est Swing 2.0"), les RIA, les mobiles et la TV sans en avoir les moyens ni les ressources (voir plus bas). Il en résulte un développement lentisssime de la plateforme qui reste limitée par le fait qu'i faut que l'API (malgré la présence de profiles) reste cohérente sur toutes les plateformes (bordel mais qu'est ce que je me marre quand je vois un blog d'un membre de l'équipe qui s'extasie devant le fait qu'il a réussi a faire tourner son app sur une TV sachant qu'il faudra encore longtemps pour que ces périphériques soient dispos auprès du grand public... et on cherche également encore les mobiles supportant officiellement FX).

En interne, la plateforme FX est bien plus avancée que sa version publique. Outre le fait que je soupçonne que le petit film avec Gosling qu’on a eut a la JavaOne de l’an dernier a été réalisé en FX, cela fait plus d’1 an et demi que divers blogs (dont celui de Chris Oliver, le créateur de F3) montrent des screens en 3D (et je veux dire avec des vrais objets 3D, pas avec la pseudo 3D qu’on peut faire avec la 1.3).

F3 a commencé comme un language de scripting pour créer facilement des apps Swing et du jour au lendemain, JavaFX s’est retrouvé projeté plateforme RIA universelle (probablement un commercial qui a eut une idée de génie).
En plus cela semble être vraiment être une décision de dernière minute puisque lors de la sortie de la version 1.0, tout le monde avait été surpris des modifications apportées et de tout ce qui était faisable durant les betas qui avaient été cassé, une bonne partie des wrappers swing avaient disparus, etc.

Le pire reste encore la non-possibilité d’intégrer FX dans les apps existantes. Là clairement c’est ce qui a tué la plateforme durant les premiers mois. Du coup FX a perdu tout intérêt potentiel pour 90% des programmeurs AWT, Swing voir SWT.

- un manque flagrant de ressources humaines et financières: Sun n'a jamais eut les reins assez solides pour réaliser les investissements nécessaires à ses ambitions. C'était déjà le cas pour Java2D et Swing (et la JavaFX a vampirise les équipés Swing) ou même avant pour des trucs comme le NC ou les JavaStations. Or, là c’est pire ils veulent gérer en interne ENCORE plus de trucs qu’avec Java. On se retrouve exactement dans le même cas qu’il y a 15 ans quand Java était supposé devenir un acteur majeur dans le milieu du desktop, Corel annonçant une version de sa suite bureautique en Java, etc. et… plus rien… avec le cas de figure actuel Java très présent cote serveur et presque inexistant coté client desktop (et les principales apps que je connais sont en SWT pas en Swing).

D’un autre coté je me demande vraiment ce que certains foutaient chez Sun à part pondre des démos techniques en Interne à longueur de journée (démos qui ne sont jamais elles-mêmes dévoilée publiquement ou transformées en exemples ou applications utilisables) au lieu par exemple d’ajouter des composant Swing ou des contrôles FX dans l’API.

Un autre domaine où cela semble être fortement visible c’est le support des media. Outre le fait que personne chez Sun ne semble avoir réactiver le projet JMF si essayé de voir s’il était possible d’intégrer les divers codecs JMF ou autre frameworks media qui sont apparus au cours des années, ils se sont contenté d’aller licencier une technologie tierce fortement limitée et encore moins finalisée sur toutes les plateformes lors de la sortie de la 1.0 (et apparemment la lecture de vidéos sous Linux ce n’est pas encore ca). Et d’un autre coté de se reposer sur les codecs natifs c’est bien pour l’accélération… mais /doh c’est totalement contradictoire avec le fait d’avoir voulu faire un outil universel.

J’aimerai également bien savoir si le projet JavaStore n’a pas non-plus lui aussi vampirisé trop de ressources critiques qui auraient été bien mieux allouées ailleurs.

- des outils inadaptés (une partie est causé par le manque de ressources) : passons sur l’outil d’Authoring dont on a plus entendu parler depuis la JavaOne (me demande encore comment ils avaient bien pu pondre une telle app avec toutes les limitations et les bugs de la 1.2… même le Composer est loin de présenter tout le degré de fonctionnalités que l’outil d’Authoring laissait entrevoir. Enfin, passons - PS : voir plus haut concernant la version de FX interne a Sun/Oracle).

Reste que et Adobe et Microsoft ont su mettre en place leurs outils de design bien avant de faire que leurs langages et ses outils de devel viennent s’y raccrocher (Expression Studio Design est dérivé d’une app rachetée par Microsoft et adaptée pour créer des design pour Vista et le web puis modifiée pour supporter Silverlight). Ici on a le language, l’API et… rien… ne pas vouloir redévelopper un Designer quand on manque de ressources certes, ca part d’une bonne idée (même si personnellement, je suis contre, ca coute très cher à acheter la suite CS), mais bon au final les convertisseurs de la Production Suite sont incomplets et ne produisent les résultats escomptés dans bien des cas compte de tenus des bugs existant en Java2D (dont certains existent depuis des éons dans la bugdatabase) ou de limitations de l’API qui ne seront pas corrigées avant Java xxxxx (si jamais elles le sont, je pense a cette stupide idée de ne pas permettre les stops sur les mêmes valeurs dans les gradients par exemple) et donc cela rajoute pas mal d’étapes intermédiaires dans la chaine de production pour faire les conversions et checker la qualité des dites conversions. Pire, pour une entreprise pourquoi avoir besoin d’un designer + un programmer la où seul le designer suffit la plupart du temps quand on a Flash (pour reprendre l’exemple de la simple bannière animée) ?

Le plugin NetBeans fonctionne (encore heureux) mais le support reste buggé et pas mal archaïque par bien des coté (le deboggeur ne fonctionne toujours plus dès qu’on rentre dans du cote Java). Les supports dans Eclipse, Maven et JDeveloper avancent au bon vouloir de projets externe (comme pas mal de projets OpenSource de petite envergure, ca avance au petit bonheur la chance).
Reste le Composeur. Une bonne chose mais idem le manque de ressources + les limitations même de l’API fait que son développement est super lent. En fait quand il sera pleinement fonctionnel, la problématique sera strictement identique à celle du projet Matisse : c’est super et tout et tout mais ca arrive juste 5 ans en retard.

Les outils de distribution sont juste mauvais. Passons aussi sur le déploiement hors ligne, on sait ce qu’il en est : inexistant. Pourquoi un particulier ou une (petite) entreprise irait se faire littéralement chier avec Java Web Start et toute sa lourdeur et tous les bugs récemment introduits dans Java 1.6.0_12 à 1.6.0_19 alors que le déploiement d’une app en Flash ou Silverlight passe comme une lettre à la poste ?

- une politique bizarre : on citera en vrac, la license concernant la redistribution des runtimes, le fait que dans la 1.3 on ne peut plus packager ses medias dans ses JARs, etc…

- un mauvais timing : la crise, la banqueroute, les délais dans le merging du aux différentes autorités de régulation. Bref, FX est sorti et a été publicité au mauvais moment.

Accéder aux sources (notamment ceux des contrôles existants) ca peut aider pour certaines choses (créer nos propres contrôles de la « bonne manière », proposer des correctifs pour les contrôles existans), ca y a pas de problème. Mais on pouvait accéder aux sources de Java bien avant que Java ne deviennent OpenSource, juste la notice de copyright était différente. Le fait que ce soit OpenSource est bien secondaire, il n’y a guère que les extrémistes de l’OpenSource que ca gênait a l’époque.

Citation:

---

Envoyé par Traroth2

En l'occurrence, si 15 frameworks étaient vraiment sortis pour JavaFX, c'est la meilleure chose qui aurait pu arriver. Un tel foisonnement aurait été 100% positif, même incompatibles entre eux, et même si 12 s'étaient éteints au bout de 4 ans. Parce que dans les faits, il faut constater que c'est plutôt le calme plat de la mort clinique, du côté de JavaFX...

---

C'est pas un truc propre a FX mais a JAVA tous entier, plein de framework de tous les cotés, certains sont géniaux, d'autres sont mort et enterrer depuis des lustre et n'apporte rien de bien sauf des bug...

Citation:

---

Envoyé par yoyo88

C'est pas un truc propre a FX mais a JAVA tous entier, plein de framework de tous les cotés, certains sont géniaux, d'autres sont mort et enterrer depuis des lustre et n'apporte rien de bien sauf des bug...

---

+1000

Citation:

---

Envoyé par yoyo88

C'est pas un truc propre a FX mais a JAVA tous entier, plein de framework de tous les cotés, certains sont géniaux, d'autres sont mort et enterrer depuis des lustre et n'apporte rien de bien sauf des bug...

---

S'ils sont morts et enterrés, qui est-ce qu'ils dérangent ? Pas moi, en tout cas.
C'est ce foisonnement de créativité qui fait la richesse de Java !
Et ce qui est sûr, c'est que, vu la manière dont fonctionne le monde open-source, pour un Spring, il faut 3 ou 4 projets qui se terminent en eau de boudin.

Le résumé du message de Bouye tel que je le comprends, c'est que Sun n'avait pas les moyens des ambitions qu'il avait pour JavaFX, et là, je pense que la communauté open-source aurait pu apporter beaucoup.

Citation:

---

Envoyé par Traroth2

S'ils sont morts et enterrés, qui est-ce qu'ils dérangent ? Pas moi, en tout cas.

---

ceux qui ont décider de développer avec et qui se retrouve le bec dans l'eau...

Citation:

---

Envoyé par Traroth2

C'est ce foisonnement de créativité qui fait la richesse de Java !
Et ce qui est sûr, c'est que, vu la manière dont fonctionne le monde open-source, pour un Spring, il faut 3 ou 4 projets qui se terminent en eau de boudin.

---

la richesse de java c'est aussi sont plus gros défaut.
y'en énormément de framework certains sont les leaders dans leurs domaine, mais des qu'il s'agit de regrouper le tous pour faire un standard, sa merde... il y a très peu voir aucune cohérence entre tous ses framework.
Résultat, certains se marche sur les pied, les standard on 3 ans de retard, certains projet qui ont l'air prometteur tombe a l'eau... bref c'est le bordel.

Citation:

---

Envoyé par Traroth2

Le résumé du message de Bouye tel que je le comprends, c'est que Sun n'avait pas les moyens des ambitions qu'il avait pour JavaFX, et là, je pense que la communauté open-source aurait pu apporter beaucoup.

---

la part contre je suis d'accord, si SUN/Oracle n'a pas les moyens de faire quelque chose, alors autant passé en open source.

Citation:

---

Envoyé par yoyo88

ceux qui ont décider de développer avec et qui se retrouve le bec dans l'eau...

---

Mouais... Personnellement, je ne commence pas un projet ayant pour moi une certaine importance en utilisant des outils dont je ne suis pas sûr de la pérennité...

JavaFX devient « JFX » et open-source
Oracle propose formellement la technologie à l'OpenJDK

Mise à jour du 3 novembre 2011 par Idelways


Oracle tient sa promesse engagée en marge de la dernière conférence JavaOne. JavaFX est aujourd'hui formellement proposé à devenir open source dans le cadre du projet OpenJDK.

Le Toolkit de développement d'applications client riches en Java s'appellera « JFX » et pourrait faire « partie intégrante du JDK » dès Java 9, déclare Richard Bair sur la mailing-list de la version libre du langage.

« Nous en avons parlé depuis longtemps, mais finalement (enfin !), nous sommes prêts à agir et ouvrir les sources de la plateforme », déclare le porte-parole de l'équipe JavaFX, pressenti pour conduire le projet open source. Bair explique par la suite que la réelle motivation de cette démarche est d'aboutir à un modèle de développement ouvert et transparent.

Le code ainsi offert représente 6000 membres d'API (constructeurs, méthodes publiques...), 11 500 tests unitaires, des librairies Core, Scene Graph, effets, support du CSS et de l'accélération matérielle, des contrôles d'interface utilisateur et de graphes...

Le vote aura lieu le 16 novembre prochain. Les composants de la technologie seront libérés progressivement à commencer par les contrôles. À terme, OpenJFX ne dépendra plus de binaires.

La licence open source qui signera le code n'est pas encore connue (ou dévoilée). La GPLv2 avec l'exception Classpath reste toutefois le choix le plus probable.



Source : mailing-list d'OpenJDK

Et vous ?

:fleche: Que pensez-vous de cette démarche ?
:fleche: Quelles sont d'après vous ses réelles motivations, et retombées sur l'écosystème Java ?

Ouais, ben, deja qu'ils sortent une version du SDK 2.0 sous Linux, ça m'arrangerait >< Parce que quand on lit "le support de Linux sera apporté dans une version ultérieure", ça rassure pas... Surtout quand on voit que le support Mac OSX, lui, devrait être apporté rapidement.

Teo, "chouette, la version 2.0 est sorti, p'tet l'occasion de voir ce qu'il a dans le bide... ah ben non"

Excellente nouvelle, mais tard, tellement tard.

Je me demande quand même ce qui va advenir des technos tierces incorporées à JavaFX, comme le codec VP6...