Forums : Divers, vos projets, le site...

Au fait SUN a annoncé que l'ensemble de Java serait basculé en Open source lors de JavaOne 2006. La pression est trop forte sur ce point.

Pour une JVM open source il y a Harmony pour la plus connue qui est faite par la fondation Apache. http://www.01net.com/article/280038.html

Sinon pour une liste de JVM free : http://klomp.org/mark/free-vm-benchmarks/

Le problème n'est pas "Comment je vais faire ceci ou cela" mais avec "quelle API je vais le faire" (JDK, projet Open Source Java, produit commercial)

Bon, attention à ne pas non plus tomber dans le "pro-Java" mais rester objectif et pragmatique Sinon ce post va finir hors sujet

oschmitt et clement : vous confondez langage et API.

En tant que langage/technologie, XUL, XBL, XPcom &cie n'ont rien à envier au langage Java.

En tant qu'API, je crois que 99% des gens s'en tamponnent qu'il y ait dans Java une api pour l'imagerie médicale ou pour réaliser une base de donnée.

Tout ça on pourrait le faire aussi avec la plateforme Mozilla. no limit. Seulement, ces API n'ont pas été (encore) réalisées, parce que la plateforme est jeune vis à vis du grand public.

En tant que langage/technologie, XUL, XBL, XPcom
&cie n'ont rien à envier au langage Java.

En tant qu'API, je crois que 99% des gens s'en
tamponnent qu'il y ait dans Java une api pour
l'imagerie médicale ou pour réaliser une base de
donnée.

Il n'y a pas d'API spécifique pour l'imagerie médicale mais une API pour la mainpulation d'image qui est très puissante, l'imagerie médicale étant un cas d'utilisation (scanner, IRM,...).

Tout dépend de ton projet, et de tes besoins. J'ai travaillé sur un projet web ou je devais généner des images et manipuler les palettes de couleurs des des dites images. Je peux te dire que je ne m'en foutais pas d'avoir une API comme celle çi. C'est sur que pour des petits projets au périmètres techniques limités c'est tres bien mais quand tu commences à devoir te conencter sur de systèmes différents (mainframe, LDAP, SGBDs, webservices, transactions distribuées,...), et avoir des problématiques techniques complexes (batches périodiques, crytpage de documents, génération d'images,...), tu es bien content de pas avoir besoin de plusieurs plateformes technologiques pour t'en sortir.Et ce genre de contraintes c'est le lot des applications d'entreprise (moyennes ou grosses). C pour ça que J2EE a été fait.

Tout ça on pourrait le faire aussi avec la
plateforme Mozilla. no limit. Seulement, ces API
n'ont pas été (encore) réalisées, parce que la
plateforme est jeune vis à vis du grand public.

Ha ok si on part sur ce que l'on pourrait faire dans six mois, un an ou deux sans si jamais la fondation Mozilla voulait bien développer telle API ou telle autre, alors là c'est sur on peut imaginer n'importe quoi. Je parle de que l'on peut faire la tout de suite (pas dans le futur).

Sinon, je trouve que XUL est très puissant pour la partie interface. Je voudrais que lorsqu'on parle d'une techno contre Java on soit plus précis : le langage, les APIs standards (J2SE,JEE,...), ....

"Ha ok si on part sur ce que l'on pourrait faire dans six mois, un an ou deux sans si jamais la fondation Mozilla voulait bien développer telle API ou telle autre"

Je pense qu'en Java enormement des API disponible ne sont pas produite par Sun, mais par des contributeur tiers.

Donc dans le principe "n'importe qui" pourrais faire une API pour la manipulation d'images, et la mettre a disposition. (gratuitement ou non, là n'est pas le debats)

L'avantage de Java par rapport a Mozilla réside certainement dans la quantité de contributeur. Il en devient presque difficile en Java de ne pas trouver quelqu'un qui a "deja fait" ce que vous etes en train de faire. Avec la techno mozilla, il reste enormement a faire (bien que les bases soit là )

Sinon effectivement, il est difficile de comparer Java et Xul dans leur intégralité, mais on peut comparer la création des UI (Xul pur donc). Et pour moi il est beaucoup plus simple et flexible d'utiliser Xul que les UI Java:

* courbe d'apprentissage plus longue vu le nombre
de technologie que l'on peut utiliser

Moi personnellement, j'ai plus ou moins imposé XUL pour developper une grosse appli au taf, server d'appli, java, moteur de workflow, oracle, architectures repliquées, et j'en passe, le cahier des charges etait de faire du client léger. Mais les besoins client, imposaient un client riche. On s'est "naturellement" tourné vers XUL (j'ai un peu forcé ), et ayant une bonne connaissance des techno web, et de java, l'apprentissage, à etait assez aisé. Ayant experimenté les interface en java via swing, je peux dire qu'il n'y à pas photo XUL, c'est facile. nous utilisons l'appli en distant, donc pas de chrome et XPCom, mais nous avons reussi à surmonter la plupart des problemes que cela impposait (pas d'observer sur les rdfs entre autre).

XML nous permet mettre en forme les données independement du language qui les traitera. XUL permet de faire la description des interfaces, à opposer à HTML qui lui decrit des presentations. XBL permet vraiment de se faire ses propres "balises" reutilisable surement le truc le plus puissant de XUL. CSS permet de definir les styles JS de gerer l'interaction client-application JAVA de faire le traitement coté server (Architecture J2EE) RDF de peupler les elements de l'interface. AJAX permet de faire les requetes server en recuperant les resultats en XML. Et j'en oubli surement. Je ne peux que conseiller XUL. Quand je suis arrivé sur l'appli que nous develeppons au taf, c'etait du client pauvre, comme je connaissais bien DHTML, j'ai tenté de transformer tous ça en client riche via DHTML. Non sans reussite, mais la complexité etait telle que le chargement des pages c'est mis violement à ramer. Je ne parle même pas de la maintenance des pages qui devenait impossible. La techno des Servlet, JSP ou il faut dans la JSP melanger HTML, JS, JAVA dans une meme page est à mon sens tres mauvaise. Je rajouterais que si vous utilisez un proxy cache, comme c'est notre cas, seule les pages dynamiques son sytematiquement redemmandaient au server. c'est a dire les XML et les RDF, des JSP pour nous. Toutes les autres XUL, JS, CSS, XBL etant statiques, peuvent etre recuperées sur le proxy ou même dans le cache du navigateur. D'ou une baisse de charge importante pour le server.

XUL à repondu à mes attente sur bien des points. même si il y a encore des points noirs :

• evolution permanente, donc parfois non retrocompatibilé (j'ai des exemple...)
• Quelques bug dût à la jeunesse encore.
• Quelques plantages de Firefox imcomprehensif hélas...
• il vaut mieux avoir une connection internet sur son poste de travail, pour faire des recherches, didactitiel, et autre bout de code.
• Comme toutes nouveautés, vous risquez de vous retrouver tout seul, personne ne peut vous aider sur votre lieu de travail (heureusement qu'il y à des site comme XULFR, merci à tous ceux qui y participent)
• A quand un plugin Gecko pour Internet explorer pour fermer le claqué à tous les detracteur de XUL car Firefox moins diffusé. (Il existe bien un "plugin" pour utilisé le rendu de IE dans un onglet Firefox)

Pour finir, je vous dirais que nous avons proposé aux clients, les deux version une en DHTML et une autre en XUL. pendant la validation de l'appli. 5min après notre explication sur comment passer de l'une à l'autre, les clients ont appelé, pour nous dire qu'il n'y avait pas photos, plus rapide, sensation de stabilité, plus ergonomiques... etc. La version XUL a recu tous les suffrages.

Donc vive XUL.

La prochaine etape pour nous, sera de proposer une version de l'appli qui s'installera comme une extention de firefox, mais en utilisant la même architecture. avec quelque XPCom en plus surement.

Je pourais encore disserter des heures sur XUL, Mais pour revenir au sujet du post original, XUL vs JAVA. Dans notre cas, application distante, architecture J2ee, ces 2 technos ne sont pas du tout en concurence, mais complementaires. On devrais plutot opposer FLEX XAML ou même SWING, mais pas JAVA.

En tous cas XUL m'a totalement convaincu, je suis un peu l'evangelist XUL sur mon lieu de travail. Mais ça, si vous m'avez lu jusqu'ici vous aurez aucune peine à le croire...

Tout a fait d'accord sur le mariage XUL-Java.

Je viens du monde Java comme vous avez pu le constater et j'ai marié dans les deux dans mon projet Open Source : http://xulfaces.sourceforge.net.

JSF (avec le reste de J2EE) + XUL : ça fait un couple du tonerre.

Pour ce qui est de la création d'interfaces XUL est GENIAL !!

Je souhaite pour ma part que XUL évolue par l'ajout de nouveaux composants graphiques dont certains sont en cours et par la stabilisation des versions de Firefox.

JSF (avec le reste de J2EE) + XUL

Tu veux dire qu'à partir d'un fichier XUL, tu génères une class Java ?

Pour mapart, ce n'est pas l'idéal.

L'idéal est de conserver XUL (XUL+XBL+JS+CSS+SVG+etc) avec le moteur Gecko car la complexité des technos est MONUMENTABLE et trop difficile à réimplémenter dans son ENSEMBLE en Java.

Par contre, pour la couche applicative, Java est effectivement le top. Avec la possibilité de réutiliser toutes les APIs Java disponible. L'ouverture des possibilité est immense.

• > Du coup, il faut continuer le développement de JavaXPCom.

Sinon, le gros point faible reste quand même de devoir posséder en plus de Gecko une JVM. Du coup ... pourquoi ne pas envisager de compiler Java en langage natif en fonction du ou des OS qu'on vise. On pourra alors s'affranchir de JVM.