Open source et architecture logicielle

C'est bien la question que je me pose en abordant le smartphone ...
C++ ou Java ?
Après avoir écrit un antispam (PHP + CURL) sous Linux (c'est mon langage de travail).
j'ai voulu le récrire sous C++ (pour m'y mettre enfin), pas trop de souci, hormis les pointages vers les bonnes bibliothèques CURL
Puis le passage sous Android, le C++ bien qu'Android soit sous Linux, ne semble pas fonctionner sans un NDK qu'il me reste à maîtriser.
J'ai lu ici ou là que Java était natif sur Android...
Je vais tenter l'aventure...

Swing n'évolue certes plus, JavaFX peut-être plus non plus dans un proche avenir, mais SWT continue d'être développé il me semble.
Pour créer un client lourd multi-plateforme, Java reste la meilleure solution. Qt (et GTK, qui avec Gimp existe aussi sous Windows) nécessite quand même de recompiler son code, et pour les utilisateurs Windows, d'installer la librairie ce qui n'est pas rien (alors que le JRE sert déjà à tellement de choses que presque tout le monde l'a déjà installé pour une autre raison)
Les interfaces C# sont peut-être plus jolies, mais Microsoft s'est bien gardé d'inclure Win.Forms dans la spécification qu'il a soumis à l'ECMA : du coup même Mono, s'il propose une implémentation de cette interface, ne peut garantir la compatibilité à long terme.

La question posée par le billet est incomplète : tout dépend si l'aspect multi-plateforme est important ou non.
Si oui, Java reste encore le plus simple.
Et si on parle de client lourd, et non d'application autonome, ça veut dire qu'il y a un serveur qui fera une partie du travail, donc que le client n'aura pas forcément à faire les calculs les plus complexes susceptibles de ralentir l'interface vue par l'utilisateur.
Mais si c'est pour déployer sur une seule plateforme, à l'échelle d'une entreprise par exemple, alors votre OS dispose sans doute d'une GUI dédiée bien plus rapide, même en comparaison de SWT.

@a028762 ,
Pour android pas de soucis, c'est du java certes, mais l'interface utilisateur vient avec son propre framework !

L'avantage que je vois c'est que j'ai un seul langage pour faire aussi bien du client lourd que des sites web avec JEE/JSF.

Envoyé par Népomucène

L'avantage que je vois c'est que j'ai un seul langage pour faire aussi bien du client lourd que des sites web avec JEE/JSF.

C# peut le faire aussi ... ? !

Si on vise le client lourd multiplateforme Java a tout de même un avantage colossal vis-à-vis de la concurrence. Je sais que pour avoir pas mal joué avec Qt ce n’est pas du tout aussi évident (une fois que le code compile sur la plateforme de dév, le boulot est loin d’être terminé pour voir son programme fonctionner sur d’autres plateformes), quant à .Net c’est une superbe plateforme, mais comme dit plus haut, pour du client lourd (en WPF comme en Winforms) on signe avec Windows et personne d’autre.

Du coup, tout dépend où l’on souhaite placer le curseur ; performances / multiplateforme / UX et IHM parsemée d’effets choucroutes. Chacun aura son domaine de prédilection.

Je pense que la question sera encore plus pertinente dans un mois, après la conférence BUILD, puisque l'on devrait savoir dans les grandes lignes ce que microsoft compte faire de Xamarin, et si celui-ci est intégré complétement dans Visual studio. Dans ce cas le couple UWP + Xamarin risque de devenir un atout important dans la manche de microsoft...
Si c'est le cas je prédis un bel avenir à UWP/C# et une très forte odeur de sapin autour de java et de ça plateforme vieillissante.

J@ck.

En entreprise, l'avantage énorme de Java et que c'est une compétence particulièrement répandue.
Il ne faut pas juste se poser la question de la performance mais aussi celle de la maintenance et pour le coup, Java dépasse tout.
On peut facilement et rapidement trouver un prestataire en mesure de reprendre le code avec TJM qui n'explose pas le budget.

Rien que le terme client lourd est mal approprié. Le java franchement je n'y crois pas.

Mais bon un Language lourd pour client lourd ca semble logique...

S'il faut démarrer un tout nouveau projet, à moins que Java soit un prérequis ou imposé, je pose aussi cette question. Niveau client lourd, le principal avantage de Java par rapport à tous les autres est celui de la portabilité sans nécessiter de recompilation : un fichier JAR s’exécutera de la même façon sous Linux, OSX ou Windows (pour peu qu'il ne fasse appel qu'à des fonctions portables. Mais je trouve que les langages .NET, et plus particulièrement le C# sont un meilleur choix aujourd'hui, on dira peut être simple question de feeling, le C# est plus facile à aborder que le Java, ses bibliothèques fournies par défaut sont riches et la facilité avec laquelle concevoir des interfaces graphiques sans taper beaucoup de lignes de code est assez bien faite (j'ai déjà réalisé une interface graphique en C# avec rien qu'un bloc notes, le même code en Java prend une tournure beaucoup plus complexe à mon goût. Le reste, je pense que c'est une question de goûts, Java est loin d'être mort (bien que ceci plairait à beaucoup) en ce qui concerne les applications de bureau.

Mais à l'heure où l'on parle de plus en plus d'applications Web ou Cloud, on peut encore se poser des questions s'il faut se lancer dans un projet 100% client lourd : remarque que j'ai déjà entendue par exemple "C'est fini les grosses applications qu'on installait sur une tour et tournaient avec une base de données locale, les habitudes des utilisateurs ont changé, ils veulent de la mobilité, un accès à partir de n'importe où etc". Je trouve ça assez juste. Je me déporterais plus vers des applications hybrides faisant appel à des services etc. Le client lourd peut rester pour faire principalement les traitements consommateurs, le reste doit selon moi se déporter le plus possible vers des applications Web (ex typique : Google Docs, sans aucune installation).

a l'heure actuelle, les deux seuls choix pour faire du single source code pour plusieurs plateformes sont C++/Qt ou Java/Javafx ou swing... C# n'est pas une option car il n'y a pas de ui portable.

J'ai recemment fait un client Java8 et javafx, j'ai bien aimé et c'était agréable à programmer et rapide à l'execution.

J'avais hésité à utiliser Qt mais Java est plus facile à deployer et JDBC me permettait de me connecter à ma DB de n'importe quel OS.

donc au final: Java

Rôlàlà, je vais être mauvais mais à ce paragraphe :

Java est porteur d'une rigueur qui s'exprime à travers l’élégance du langage dès les premières phases de programmation qui s'impose aussi bien aux développeurs qu'aux chefs de projet. Cette rigueur s'exprime durant tout le cycle de vie du projet et dans tous les domaines

J'ai ri… Merci de m'avoir égayé ma soirée.

Sérieusement, dans la liste, le gestionnaire de source n'a rien de spécifique à Java et le monde du développement n'a pas attendu la communauté Java pour s'y mettre. Je dirai même que citer SVN montre tout de même un manque de rigueur dans la gestion des sources (certes souvent dues à l'existant) de la communauté. Idem, les tests unitaires (entre autres sur les notions de "qualité") n'ont rien de spécifique à Java. Enfin, les IDEs cités, si j'ai peu de problèmes avec NetBeans, citer Eclipse qui se caractérise certainement comme l'IDE sur lequel on passe plus de temps à le faire fonctionner que de produire, j'ai du mal à l'associer avec la notion de "rigueur". Il y aurai IntelliJ, je n'aurai rien dit sur ce point… Enfin, Maven (pour ceux qui ne sont toujours pas passé à Gradle, quoi que…), c'est surtout le patch de la gestion du cycle de développement.

Sur la partie

Mais nous savons également que l'écosystème Java est d'une puissance inégalée dans le monde de l'open source ne serait-ce que pour la richesse de ses API.

Par "monde de l'Open Source", on parle de quoi exactement ? Car dans la communauté Open Source, Java est loin d'être considéré comme autre chose qu'un jouet face à C++ ou d'autres technos "libres". Bien sûr, Java est loin d'être un "jouet", mais il est avant tout une techno "corporate". Et c'est bien en s'imposant dans ce domaine que l'accent a été mis sur les frameworks web… Du coup, le besoin de "clients lourds" concerne qui ? Et surtout aujourd'hui alors qu'une partie des usage s'oriente vers la mobilité ?

Le plus adapté est celui que j'utilise Une vielle technologie légère et multi plateforme qui fonctionne encore et encore sans jamais vouloir disparaître, c'est bien sur le couple Free-Pascal / Lazarus ...

Certes, Swing n'évolue plus. Mais quelles sont ces évolutions que vous attendez et dont l'absence rendent Swing moins séduisant qu'il ne l'était par le passé ?
Et si Swing n'évolue plus beaucoup, il y a quand même quelques librairies externes qui offrent de nouveaux composants fort utiles, et qui, elles, continuent à évoluer (JideSoftware, MigLayout, ...).
Là où le bat blesse, à mon avis, ce n'est pas tant sur Swing que sur les libraires connexes, comme tout ce qui est Media : image, son, ... Là, Java est vraiment à la ramasse, et les librairies externes peu présentes (ou peu/pas maintenues).

Le gros avantage de Java c'est sa portabilité mais aussi l'investissement en formation n'est pas jetable comme cela a pu l'etre sur les technos clients "lourd" style WPF/SL. Quand je pense au temps perdu a se former a ces langages/framework pour se retrouver avec quelque chose qui ne va pas plus loin qu'un PC (SL a quand meme durée presque ... 6 ans entre sa sortie et sa mort). WPF suit sa route meme si officiellement on n'en parle plus.
A un moment j'ai switché sur Java (comme ca ressemble a du C# et qu'android studio n'a rien a envier a VS). Aujourd'hui je ne le regrette pas car l'investissement en temps de formation est rentabilisé (que je developpe sur PC, MAC ou appli mobile via framework IHM Android).
Alors oui c'est toujours un peu long a demarrer une appli java (comme pour C#) mais au moins je n'ai pas l'impression de m'etre fait bananer.
Personnellement je ne fais des applis client lourdes que pour des outils et autres. Les applis d'entreprise c'est du client leger systématiquement + version mobile android.
Le plus gros echec de M$ pour moi c'est quand meme d'etre completement passé a coté l'idée de faire des IHMs portables.
25 ans que je developpe avec les outils M$ mais depuis l'echec cuisant WPF/SL (investissement en formation colossal pour se prendre une grosse claque dans la gueule), personnellement je reste sous Java/Android. Moins l'impression de perdre mon temps ou suivre les errements de M$ qui se cherche encore et encore.

flag

Je ne sais pas si JavaFx est une solution d'avenir (le remplaçant de Swing en plus moderne pour ceux qui ont loupé un épisode), en tout cas c'est un framework très facile à implémenter et à maintenir et qui proposent tout ce que l'on peut imaginer en terme de fonctionnalité GUI (widgets). Par contre je ne crois plus aux frameworks hypes du moment, tous reposant sur Javascript, les applications sont devenues des patchwork de plugins et de pièces rapportées et leur maintenance est devenue un cauchemar. Donc le temps fera son oeuvre et on finira par sortir des frameworks enfin rationalisés basés sur les concepts déjà éprouvés des "vieux client lourd" et alors implémenter un tableau de données paginables et triables sera redevenu un plaisir à faire et à maintenir.

Certains parlent de QT, celà fait des années que je l'utilise (à l'époque propriété de Trolltech), c'est un framework très simple à utiliser qui permet de réaliser des IHM complexes et performants le tout sans renier à la portabilité, je suis fan inconditionnel.