Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

JavaFX contre Qt Quick
Quels sont les avantages de chaque technologie déclarative pour une application de bureautique ?

Le , par epsilon68

0PARTAGES

0  0 
Hello,

Que me conseilleriez vous pour faire une appli interrogeant une database ("postgres" ou "oracle". L'aspect multiplateforme est important, au minimum windows et mac. Autre point important est que je ne veux pas d'install, l'application doit pouvoir s'installer de facon "portable" (juste en copiant un dossier).

JavaFX ou QtQuick?

JDBC me parait etre l'argument essentiel dans le choix de Java,
Et la recompilation me parait en la defaveur de Qt.

Qu'en pensez-vous?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de epsilon68
Membre éprouvé https://www.developpez.com
Le 02/03/2019 à 9:10
Je trouvais qu'il manquait un epilogue à ce thread, alors voila.
J'ai finalement pris Java puis rapidement Kotlin avec intellij et j'ai fait l'interface en javafx.
J'ai vraiment codé rapidement, et le jdbc est vraiment pratique vu que toutes les dbs le proposent.
Au final, mes apps ne sont pas lentes et peuvent tourner sans exe et sans install.
donc c'etait vraiment tout gagnant.

j'ai recemment commencé une toute petite app sur Qt/quick, pour faire une equivalence d'un autre petit programme ecrit en javafx et Kotlin (avec coroutine).

En Qt, j'ai deux classes Qt juste pour faire l'action en asynchrone, puis j'ai buté sur comment transféré une structure coté QML (finalement je viens de voir qu'on peut utiliser Q_GADGET sur une structure/class). Bon au final, j'ai transmis un QVariant mais je n'ai plus de type (et sonc d'intellisense) coté QML. J'aurais pu utiliser QWidget mais comme QtQuick c'est le futur (c'est vendu comme ca du moins) j'ai voulu faire. Bon ca ne m'a pas deplu, mais je n'etais plus habitué à faire autant d'effort pour juste un traitement asynchrone.

en javafx, j'ai fait mon xml pour la presentation, puis mon controller en kotlin, et une coroutine pour le traitement asynchrone. tres simple et resultat tres propre.

Au final ce que j'en pense, c'est que j'en viens à me demander si je devrais utiliser C++ dans le futur. (Edit: Je connais très bien le C++)
Je ne suis pas sûr, on perd un temps fou dans des details, et aussi une erreur decompil soudain apparait, longure de 3 km. ha oui fallait faire "run qmake" pour regenerer le makefile. (j'ai perdu un certain temps).

J'ai oublié de vous dire que j'ai aussi fait ce programme en cocoa objective C++, et la c'est OK, plus de probleme d'interface vraiment, c'est assez simple, le cote asynchrone avec grand central dispatch, le coté c++ va encore, xcode est mieux que Qt creator (Qt Creator a fait d'enormes progres dans intellisense, c'est remarquable). Franchement cocoa est un des meilleur framework graphique (pour moi peut etre le meilleur)

donc mon avis, c'est de prendre Kotlin, ou bien cocoa si c'est mac only. Si on veut le C++ pour des raisons de memoire (je dis pas les perf car j'ai vu que java n'etait pas lent, bien au contraire, par contre qu'est ce ca consomme de la RAM...) et multiplateforme, alors Qt. Maintenant QtQuick (2 mondes c++ javascript) ou QtWidget, Qt quick est pas mal, et peut aussi etre sur mobile, mais cette separation peut être embetante. Et finalement de nos jours, le garbage collector est vraiment appreciable, surtout avec les lambdas et le multithread où savoir qui est le owner est vraiment délicat.

edit: j'ai fait encore des tests, et je regardais la consommation memoire sur des lists de 5 milliards d'elements (avec un algo d'intersection sur deux lists) et la le java consomme 4,5 GB quand c++ consomme 240 MB
ca fait reflechir... non?
1  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 05/03/2019 à 11:46
Moi, perso, j'ai aimé le retour d'expérience que j'ai trouvé intéressant. Je comprends qu'il y ait des blocages sur l'utilisation de Qt avec le QML, car c'est une chose qui s'apprend, plus ou moins facilement. Dans d'autres langages, il n'a pas ce genre de "communication" entre deux langages/paradigmes. Mais pour autant, le QML n'est pas mauvais.

Pour la consommation mémoire en JAVA, j'avais déjà rencontré ce problème, mais n'étant pas expert en JAVA, je ne sais pas régler une telle chose. Juste, ça m’horripile une telle chose, venant d'un monde C++.

Par contre, pour l'intersection de cinq milliards d'éléments, la consommation mémoire énoncée pour le C++ me parait basse, non ? (sauf si les 5 milliards d'éléments ne sont pas en mémoire, évidemment.)
1  0 
Avatar de mintho carmo
Membre averti https://www.developpez.com
Le 06/04/2015 à 13:38
<troll>Une application Java nécessite l'installation d'une JVM, ce qui nécessite de télécharger un fichier de plusieurs centaines de Mo. Si tu fournis les sources de ton programme C++/Qt, tu n'auras qu'un dossier à partager...</troll>

Les contraintes dont tu parles (recompilation, installer) sont des détails, qui nécessite juste de mettre en place les outils de production adéquats. Ce n'est pas ce qui devrait déterminé le choix du langage.
0  0 
Avatar de epsilon68
Membre éprouvé https://www.developpez.com
Le 06/04/2015 à 13:47
je ne pense pas que la taille de la JVM soit cruciale dans le choix de la techno.
l'avantage de la JVM par exemple est d'avoir mon programme (closed source) pouvant marcher sur linux, contrairement à Qt où il y aura beaucoup plus de travail pour deployer l'appli.

Je pensais plus à la rapidité de l'interface JavaFX vs QtQuick?
est ce que Java produit toujours des impressions de lenteur?
est-ce que QtQuick est assez mature pour le Desktop?
Est-ce que QtQuick utilise beaucoup de CPU? (comme c'est basé sur JS et une machine virtuelle V4)
0  0 
Avatar de mintho carmo
Membre averti https://www.developpez.com
Le 06/04/2015 à 14:19
Citation Envoyé par epsilon68 Voir le message
je ne pense pas que la taille de la JVM soit cruciale dans le choix de la techno.
Certain n'aime pas avoir une JVM qui tourne en permanence sur leur ordi et qui l'installe pas ou ne la lance pas automatiquement.
Mais effectivement, c'est le problème de l'utilisateur, s'il en veut pas installer une JVM et qu'un programme est écrit en Java, il passe son chemin.

Citation Envoyé par epsilon68 Voir le message
l'avantage de la JVM par exemple est d'avoir mon programme (closed source) pouvant marcher sur linux, contrairement à Qt où il y aura beaucoup plus de travail pour deployer l'appli.
Non, sauf cas particulier où tu utiliserais des fonctionnalités spécifiques à Linux/Windows (par exemple, si tu appelles un QProcess pour lancer un script bash - mais le problème sera identique pour un programme Java), le code C++/Qt est parfaitement portable.

Une différence quand même est qu'il faut effectivement compiler deux fois ton application (pour Linux et Windos), ce qui nécessite d'installer les 2 OS. Mais :
1. il serait idiot de distribuer une application Java qui n'a pas été testé sur l'un des environnements, donc même avec Java, tu as besoin des 2 OS.
2. la compilation nécessite juste d'ouvrir le projet dans QtCreator et lancer le build. Et cela doit être fait qu'une seule fois, lorsque l'on distribue la version finale (ou à chaque fois que l'on fait une build stable si on fait des tests). Si cela prend trop de temps, on fait un serveur de build

Dans tous les cas, l'installation d'un environnement de build professionnel, que ce soit pour Java ou C++/Qt, nécessite un peu plus de choses que d'installer un simple IDE. Les outils sont pas les mêmes (bien que, j'utilise Jenkins pour mes projets C++/Qt), mais au final, ce n'est pas cela qui doit orienter le choix.

Citation Envoyé par epsilon68 Voir le message
Je pensais plus à la rapidité de l'interface JavaFX vs QtQuick?
est ce que Java produit toujours des impressions de lenteur?
J'utilise yEd, qui est un éditeur de graphe écrit en Java et je ne trouve pas lent (je ne sais pas si c'est du JavaFx... Java a changé tellement souvent de lib graphique que je ne sais plus laquelle est recommandée actuellement)
Donc Java peut être suffisamment rapide, s'il est bien codé.

Citation Envoyé par epsilon68 Voir le message
est-ce que QtQuick est assez mature pour le Desktop?
Qt Quick est sorti depuis quelques années, donc je dirais que oui.
En particulier, il y a des tables view, ce qui est probablement ce que tu utiliseras pour afficher tes données.
Par contre, tu auras quand même du code C++ à écrire (pour la connexion à la base de données, probablement)

Citation Envoyé par epsilon68 Voir le message
Est-ce que QtQuick utilise beaucoup de CPU? (comme c'est basé sur JS et une machine virtuelle V4)
Ta question est étrange, puisque tu compares QtQuick et Java, qui utilisent tous deux une VM. (et en fait, QtQuick n'utilise pas une VM, mais compile à la volée avec un JIT... comme Java)

Qt Quick est optimisé pour tourner sur mobile, donc optimisée pour ne pas exploser le CPU, la RAM et les performances.
Par contre, il est justement optimisé niveau graphique pour être efficace (utilisation de l'accélération matérielle via OpenGL), ce qui nécessite plus de boulot de préparation (en interne) que QtWidget et donc une utilisation mémoire plus importante. Mais on gagne en termes de performances.

Mais encore une fois, cela n'a pas de sens de comparer QtQuick seul, il faut le comparer avec JavaFx. QtQuick consomme du CPU, mais est-ce que c'est plus que l'équivalent avec JavaFx ?

Et même cette question n'est pas forcement pertinente. La question n'est pas de savoir qui est le meilleur sur chaque point particulier, mais de savoir si chaque approche repond aux contraintes minimales de ton projet. Si c'est le cas, alors tu dois choisir sur d'autres critères. (si QtQuick consomme plus de CPU que JavaFx dans l'absolue, mais que le premier consomme 1.1% de CPU et le second consomme 1.0%, est-ce que c'est pertinent de choisir l'un ou l'autre selon ce critère ?)
0  0 
Avatar de epsilon68
Membre éprouvé https://www.developpez.com
Le 06/04/2015 à 14:37
Citation Envoyé par mintho carmo Voir le message
Ta question est étrange, puisque tu compares QtQuick et Java, qui utilisent tous deux une VM. (et en fait, QtQuick n'utilise pas une VM, mais compile à la volée avec un JIT... comme Java)
QtQuick utilise la VM V4 depuis peu, et non plus V8.
V4 fait du JIT, comme Java VM aussi, mais elle reste indispensable pour executer QtQuick.

Citation Envoyé par mintho carmo Voir le message
si QtQuick consomme plus de CPU que JavaFx dans l'absolue, mais que le premier consomme 1.1% de CPU et le second consomme 1.0%, est-ce que c'est pertinent de choisir l'un ou l'autre selon ce critère ?)
est-ce que QtQuick ne consomme que 1%? et JavaFX aussi?
c'est ce genre d'info et de retour d'expérience que je recherche pour aiguiller mon choix.

maintenant, mon choix se porterait plus sur Java, mais la lenteur que j'avais observée en swing en java 1.4 (il y a quand meme longtemps) serait définitivement l'argument contre Java.
Comme tu dis, ca depend de comment on code, mais ca serait bien de voir à quel point quand même.
Perso j'utilise Oxygen, qui est aussi en Java, et ca va, c'est agréable, mais je sens une certaine lenteur, qui reste acceptable, mais en JavaFX?
0  0 
Avatar de mintho carmo
Membre averti https://www.developpez.com
Le 06/04/2015 à 14:46
Citation Envoyé par epsilon68 Voir le message
QtQuick utilise la VM V4 depuis peu, et non plus V8.
V4 fait du JIT, comme Java VM aussi, mais elle reste indispensable pour executer QtQuick.
Je ne suis pas sur que ce soit une VM, mais un simple interpréteur... (mais j'imagine que c'est une question de sémantique. Bref, osef)

Citation Envoyé par epsilon68 Voir le message
est-ce que QtQuick ne consomme que 1%? et JavaFX aussi?
c'est ce genre d'info et de retour d'expérience que je recherche pour aiguiller mon choix.
Difficile de répondre dans l'absolue. Chez moi, une même application utilise entre 10% et 80% du CPU (voir plus, mais c'est quand on affiche une trentaine de flux vidéo en même temps)
Tout dépend de ce que tu mets dans ton interface

Citation Envoyé par epsilon68 Voir le message
maintenant, mon choix se porterait plus sur Java, mais la lenteur que j'avais observée en swing en java 1.4 (il y a quand meme longtemps) serait définitivement l'argument contre Java.
Comme tu dis, ca depend de comment on code, mais ca serait bien de voir à quel point quand même.
Perso j'utilise Oxygen, qui est aussi en Java, et ca va, c'est agréable, mais je sens une certaine lenteur, qui reste acceptable, mais en JavaFX?
Tu n'as pas dit ce que tu voulais faire avec JavaFx, donc : cela dépend
0  0 
Avatar de epsilon68
Membre éprouvé https://www.developpez.com
Le 06/04/2015 à 14:57
je veux faire des accès database, comparer des fichiers, afficher des differences, générer quelques reports, parser des fichiers...
l'interface serait relativement simple: des listes de fichiers, des checkboxes, des textareas pour afficher les différences...
rien de bien compliqué

pour Java:
+ JDBC
+ portable après compilation (ca n'empêche pas de tester sur toutes les plateformes bien entendu)
- jflex/cup pour le parsing, par contre pas de wildcard (vs lemon)
+ generation de report excel facile
+/- lenteur?

pour C++/QtQuick:
- deployment fastidieux
+ lemon (avec wildcard)
- report excel impossible ou très difficile
+ UI attrayant avec QtQuick
+/- CPU?
0  0 
Avatar de Jiyuu
Rédacteur/Modérateur https://www.developpez.com
Le 06/04/2015 à 16:14


Afin d'être sûr de ne pas faire fausse piste, je vais me permettre de poser quelques questions qui peuvent paraître bêtes mais qui ont, selon moi, leur importance.

Tout d'abord, lorsque tu parles d'utiliser Qt Quick, tu entends bien par là utiliser QML ?

Sauf erreur de ma part, un code QML ne peut pas se lancer seul. J'entends par là qu'il faut obligatoirement l'associer à du C++ (Qt) ou du Python (PyQt) par exemple, à moins de créer un exécutable standalone de qmlscene. (au passage si tu optes pour cette solution ça m'intéresse ).
Si tu optes pour du C++/QML tu devras forcément passer par de la compile. Si ce n'est pas toi, alors ça sera les utilisateurs de ton programme.
Si tu optes pour du Python/QML, pas de compilation obligatoire, mais il faudra avoir PyQt (et donc Python) d'installé...

Le choix du SGDB (postgre ou oracle) est-il réellement arrêté ? Car si oui tu devras forcément passer par du Qt pour recréer un nouveau composant QML permettant de manipuler ces bases de données. Malheureusement le module LocalStorage de QML ne gère que des bases Sqlite, et il ne me semble pas avoir vu quelques choses de nouveau dans cette partie pour Qt 5.5.

Concernant la vitesse de traitement, je travaille actuellement sur la création d'un ERP en PyQt / QML. Actuellement je n'ai eu à coder que du QML. Tout est très fluide.
J'ai eu à utiliser un autre ERP écrit en Java et guère plus complexe que le mien ... et bien très sincèrement et même si c'est sûrement très subjectif le mien est plus rapide... ne serait-ce qu'au lancement.

J'ai eu à faire quelques tests de rapidité entre un code 100% QML lancé par un script Python et un code 100% Python : avantage au QML.
Sauf erreur de ma part, Python n'a pas à rougir devant les performances de Java, donc ...

Pour finir, tu parles de faire un code closed source. Je suis loin d'être un spécialiste des licences, mais as-tu vérifié que ceci soit possible avec Qt ?

Avis personnel : moi j'opterai pour Qt Quick + open source

Bonne continuation à toi.

++

J
0  0 
Avatar de epsilon68
Membre éprouvé https://www.developpez.com
Le 06/04/2015 à 16:58
Oui QtQuick est basé sur QML.
Aussi oui j'utiliserais c++ pour code applicatif.
En outre pas de prob pour sqlite (j'ai une lib pour ca), et j'utiliserais QtSql pour me connecter a Oracle et Postgres.
En ce qui concerne la license, Qt est LPGL donc c'est bon.
Maintenant pour mettre l'appli dans le store, il faudra surement une license, ce qui est embetant quand meme.
0  0