Journal QT Jambi final version released

Posté par  .
Étiquettes : aucune
0
6
juin
2007
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).

  • # Faire un effort...

    Posté par  . Évalué à 4.

    Tu aurais pu faire un effort sur le titre du journal, ce n'était pourtant pas difficile aujourd'hui :
    "Qt Jambi débarque", "Jour-J pour QT Jambi" ou encore "D-day jor QT Jambi", si tu tenais vraiment à l'anglais.

    -->[]

  • # Plus que des widgets

    Posté par  (site web personnel) . Évalué à 4.

    « En gros ça permet d'utiliser Qt pour gérer les ecrans de vos applications java »

    Ç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  . Évalué à 2.

      Exact !
      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  . Évalué à 5.

        Et ça apporte quoi par rapport à la gestion des threads intégrée à Java ? à l'API réseau intégrée à Java ? à l'API de dessin intégrée à java ?

        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  . Évalué à 3.

          L'intérêt de cette bibliothèque est double à mon avis :
          * 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  . Évalué à 4.

            Oui, oui pour le look&feel pas de problème, c'est un des reproches faits à Java, son manque d'intégration avec le reste du système à ce niveau là (en même temps c'est pas simple non plus).

            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  . Évalué à 3.

              Je pense que tu as raison, l'interêt des API réseaux ou Thread Qt par rapport à celle du JDK n'est pas évident.
              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  . Évalué à 3.

              OK, j'avais lu un peu rapidement ton premier message.

              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  . Évalué à 5.

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

    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  . Évalué à 3.

      Est-il possible de transformer une application utilisant JWS en un paquet pour l'installer sur une machine sans connection internet ?

      • [^] # Re: Java Web Start

        Posté par  . Évalué à 3.

        Est-il possible de transformer une application utilisant JWS en un paquet pour l'installer sur une machine sans connection internet ?


        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  (site web personnel) . Évalué à 1.

          Tien, toi qui a l'aire de suivre le sujet. Concernant JWS, sera-t-il dispo sur x86_64 avec Java7?

          • [^] # Re: Java Web Start

            Posté par  . Évalué à 1.

            Tien, toi qui a l'aire de suivre le sujet. Concernant JWS, sera-t-il dispo sur x86_64 avec Java7?


            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  (site web personnel) . Évalué à 2.

              Moi qui pensait que cette machine virtuelle modulaire, c'était pour Java 7, et que Java 7 était prévu pour décembre. Grosse déception.

              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  . Évalué à 1.

                Tien, toi qui a l'aire de suivre le sujet. Concernant JWS, sera-t-il dispo sur x86_64 avec Java7?


                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.

                Moi qui pensait que cette machine virtuelle modulaire, c'était pour Java 7, et que Java 7 était prévu pour décembre. Grosse déception.

                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.