Bonjour à tous,
QT Jambi en version finale est enfin disponible. Nul doute que vous attendiez tous avec impatience cette version qui va enfin réconcilier les développeurs java avec l'interface graphique de leurs applications (swing visé).
Le lien vers la news :
http://trolltech.com/company/newsroom/announcements/press.20(...)
Qt Jambi est un binding java pour le framework graphique Qt (présent sur les plateformes windows, linux et macosx). En gros ça permet d'utiliser Qt pour gérer les ecrans de vos applications java, profitant ainsi des widgets de hauts niveaux de ce framework.
L'intégration à éclipse est quasi parfaite (même si pour des questions de performances je conseille d'utiliser le designer fourni avec Qt Jambi à part de éclipse).
Pour peu que vous embarquiez dans votre jar à la fois les dlls windows et les lib linux, vous vous retrouvez avec une application véritablement portable entre windows et linux (à condition que Qt soit installé bien sûr).
Journal QT Jambi final version released
6
juin
2007
# Faire un effort...
Posté par Nicolas Schoonbroodt . Évalué à 4.
"Qt Jambi débarque", "Jour-J pour QT Jambi" ou encore "D-day jor QT Jambi", si tu tenais vraiment à l'anglais.
-->[]
[^] # Re: Faire un effort...
Posté par FabienC . Évalué à 7.
[^] # Re: Faire un effort...
Posté par alexissoft . Évalué à 10.
[^] # Re: Faire un effort...
Posté par charlax (site web personnel) . Évalué à 5.
[^] # Re: Faire un effort...
Posté par Dring . Évalué à 4.
[^] # Re: Faire un effort...
Posté par André Rodier . Évalué à 3.
# Plus que des widgets
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 4.
Ça permet plus que ça en fait. Il y a aussi une API pour la gestion de threads, le dessin 2D (dont le support du SVG) …
http://doc.trolltech.com/qtjambi-4.3.0_01/com/trolltech/qt/q(...)
Le plugin pour eclipse, à l'époque où je l'ai testé, il ne marchait qu'avec la JVM 1.5 :-/
Concernant swing, ça commence à bien bouger. Je ne sais pas si c'est dû à la solution QT arrivant à petits pas … À suivre.
[^] # Re: Plus que des widgets
Posté par Calvin0c7 . Évalué à 2.
Il y a aussi une API pour le réseau.
Qt Jambi est fourni avec une application "exemple", regroupant tout un tas de petites applications qui montrent tout ce qu'on peut faire avec ces APIs (avec le code source Java associé).
Il y a par exemple un petit serveur web, dont on peux modifier la page d'accueil à volonté, un tétris etc...
Encore un effort à faire sur la javadoc cependant, qui comporte encore trop d'exemple en C++...
[^] # Re: Plus que des widgets
Posté par Sébastien Le Ray . Évalué à 5.
Nan parce que autant pour le look&feel je comprends, autant utiliser une lib qui réimplante des trucs déjà existants et portables, je vois pas l'intérêt...
[^] # Re: Plus que des widgets
Posté par Nicolas . Évalué à 3.
* pour le développeur C++/Qt : il est capable d'effectuer un développement Java sans problème, vu qu'il connaît déjà l'API. En plus, il faut avouer que l'intégration à Eclipse est extrêmement bonne [1].
* pour le développeur Java : un formidable toolkit pour le développement de client lourd, avec un look'n feel natif.
Je suis à la base un développeur C++/Qt, mais j'ai fait un peu de Swing et SWT, et personnellement, je trouve Qt Jambi beaucoup plus simple et intuitif d'utilisation que les deux précédents.
Mais c'est comme tout, on ne change pas forcément les habitudes, et je pense qu'un développeur Java utilisant SWT ou Swing ne verra pas d'intérêt à Qt Jambi.
[1] au passage, Trolltech rejoint le consortium Eclipse, ou un truc du genre
[^] # Re: Plus que des widgets
Posté par Sébastien Le Ray . Évalué à 4.
Mais je ne suis toujours pas convaincu qu'utiliser des API Threads, Réseau ou autres qui ne sont pas celles fournies dans le JDK soit une bonne chose même si ça simplifie la transition pour un développeur connaissant Qt. Les mécanismes de synchronisation et de multithreading sont déjà intégrés au c½ur de Java, aller en utiliser d'autres c'est d'une part se fermer aux développeurs connaissant Java (on peut être très compétent en Java et n'avoir aucune notion de Qt) et d'autre part aller contre l'esprit de standardisation de Java
[^] # Re: Plus que des widgets
Posté par Calvin0c7 . Évalué à 3.
Je pense simplement que quitte à faire un binding, il était facile d'ajouter un lien vers API déjà existante au sein de Qt. Libre ensuite aux développeur de les utiliser ou pas.
Pour ma part, je continuerai à privilégier celle de java, tout simplement parce qu'elles marchent très bien, et que je sais les utiliser.
[^] # Re: Plus que des widgets
Posté par Nicolas . Évalué à 3.
Un autre intérêt de Qt Jambi c'est d'offrir un outil (Qt Jambi generator) pour créer un binding Java à partir d'une bibliothèque C++ (en utilisant JNI).
Et ce serait ce générateur qui aurait été utilisé pour Qt jambi (je pense avoir lu ça sur un blog développeur de Qt jambi). Donc, tant qu'à faire, autant passer toute la bibliothèque Qt.
Ils ont quand même fait des efforts d'intégration, avec notamment l'utilisation des listes/vecteurs/maps standards Java (plutôt que leur pendant Qt).
# Java Web Start
Posté par lamiducampeur . Évalué à 5.
Pourquoi se compliquer la vie avec l'installation des jars, en utilisant Java Web Start (JWS) l'installation et l'utilisation d'appli Java est vraiment beaucoup BEAUCOUP plus simple (tous les paramètres sont dans le fichier jnlp : mémoire à allouer, jars à utiliser, classe principale, paramètres... et surtout plus de cette M$#@ de classpath). Avec JWS, une appli peut être installée en local et des liens peuvent être automatiquement créés dans le menu démarrer (Windows) et sur le bureau.
Par ailleurs, Trolltech a réussi a contourner le bogue empêchant les toolkits autre que Swing de fonctionner avec JWS sous Mac OS X, comme le montre la démo en ligne de QtJambi :
http://dist.trolltech.com/developer/download/webstart/index.(...)
A ce propos, ce bogue qui touche également SWT vient d'être résolu par Apple :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=63306
Bref le trio Java + Java Web Start + QtJambi, c'est que du bonheur : on peut enfin faire facilement et rapidement des applications pour le Desktop en Java. :-)
J'utilise QtJambi depuis plusieurs mois maintenant et franchement, je ne regrète absolument pas mon chois (et Swing).
[^] # Re: Java Web Start
Posté par archaons . Évalué à 3.
[^] # Re: Java Web Start
Posté par lamiducampeur . Évalué à 3.
Oui mais pas "paquet" au sens linuxien. En fait tu peux te faire une archive zip/tar contenant tous les jars et le fichier jnlp. Ensuite dans le fichier jnlp, tu modifies, l'attribut "codebase" du noeud "jnlp" par une url locale du style "file:///tmp" correspondant au répertoire ou tu as decompressé les jars.
Il ne reste plus qu'a lancer l'appli jnlp en ligne de commande ou en double cliquant sur le fichier jnlp.
Lors du premier lancement, tous les jars sont copiés dans le cache de l'utilisateur jnlp, les entrées dans le menu démarrer et sur le bureau sont créées si cela est précisé dans le fichier jnlp. La version en ligne de commande de JWS (jawaws) possède également une option -system pour utiliser le cache système mais je ne l'ai jamais essayée.
Pour des vrais paquets .deb ou .rpm, je pense qu'il faudra attendre Java 7 avec l'apparition des modules java.
[^] # Re: Java Web Start
Posté par Vador Dark (site web personnel) . Évalué à 1.
[^] # Re: Java Web Start
Posté par lamiducampeur . Évalué à 1.
Tu m'apprends que JWS n'est malheuresement pas disponible pour x86_64. Moi qui pensais switcher vers un linux x86_64 pour mon prochain poste de travail, je pense que je vais donc reconsidérer cette option. :-(
Les seules informations que j'ai c'est que :
- Java 7 ne devrait pas sortir avant au moins 1 an voir 2.
- Les sources de JWS n'ont pas encore été libérée en GPL à la différence de la très grande majorité des bibliothèques de classes Java standards.
Par contre Sun travaille actuellement encore beaucoup sur Java 6 : un "Consumer JRE" est apparament en préparation (une sorte de JRE minimal qui téléchargerait selon les besoins des bouts de l'actuel JRE) [1].
Il semble donc que Sun veuille que Java fasse son grand retour sur le poste de travail (dont JWS est un élément important pour le déploiement), il n'apparaîtrait pas illogique que JWS soit libéré et porté sur linux x86_64, et ce d'autant plus que le nombre d'utilisateurs de cette plate-forme est amener à croître fortement.
[1] http://weblogs.java.net/blog/chet/archive/2007/05/consumer_j(...)
[^] # Re: Java Web Start
Posté par Vador Dark (site web personnel) . Évalué à 2.
On pourra alors penser que cette JVM modulaire permettra d'étendre un peu les classes fournit en standard. Parce qu'il y a quand même possibilité d'améliorer les choses de ce côté là. Et il me semble que Sun veut éviter d'alourdire sa JVM.
[^] # Re: Java Web Start
Posté par lamiducampeur . Évalué à 1.
J'ai oublié de préciser plus haut que Red Hat a lancé le projet icedTea[1] destiné à remplacer toutes les parties du JDK qui ne sont pas sous GPL et a utiliser des outils libres pour compiler la bête. JWS fera peut être partie du lot, en tout cas cela devrait facilité le portage du JDK vers des architectures et des systèmes d'exploitation plus exotiques.
L'évolution envisagée de Java 6 ne concerne que la réduction du temps de démarrage et de l'empreinte mémoire de la JVM. Java 7 introduira par contre une vraie modularité apportant des dépendances et des dépots.
Java 7 risque encore de prendre pas mal de temps vu que les principales JSR (294, 277, 292, 308, 310, 294...)[2] ne sont pas encore finalisées et qu'il ne sortira qu'une fois qu'il sera disponible entièrement sous GPL.
[1] http://icedtea.classpath.org/wiki//Main_Page
[2] http://jcp.org/en/jsr/all
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.