IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Open source et architecture logicielle

[Actualité] Faut-il encore adopter Java pour un client lourd ?

Note : 4 votes pour une moyenne de 4,00.
par , 03/03/2016 à 23h42 (2025 Affichages)
L'objet de ce post n'est pas de revenir sur le désengagement d'Oracle vis-à-vis de JavaFX. Bouye l'a fait dans son actualité mieux que je ne saurais le faire.
Je ne parlerai pas non plus Swing qui date des années 1990 et qui a révolutionné la programmation multiplateforme.

Nous savons que les technologies Java tournées vers le client lourd sont soit vieillissantes (Swing) soit incertaines quant à leurs pérennités (JavaFX). 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.
Il est donc légitime de se demander si Java est éligible au développement d'un client lourd.

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 :
  • Gestion des sources (GIT ou SVN)
  • Construction compilation (maven)
  • Tests unitaires (Junit)
  • Intégration continue (Jenkins)
  • Offre des IDE (Eclipse, Netbeans)

Une alternative à Java devra tenir la comparaison sur les points décrits supra.
C# dans sa déclinaison propriétaire offre le même professionnalisme, avec en plus une qualité graphique des IHM produites sur les plateformes Windows supérieures.
C++ avec Qt est une alternative qui tient également la comparaison.

Néanmoins, Java conserve un avantage dans le domaine de l'ingénierie de la formation. En effet, Java dans sa déclinaison JEE lui a assuré une génération massive de compétences sur son écosystème qui demeure un atout considérable.

De plus, l'analyse faite jusqu'ici n'est valable que sur l'outil historique du monde numérique : le PC. Mais à l'heure où la moitié du monde s'aventure sur internet avec un smartphone, nous devons reconsidérer la plateforme cible des « clients lourds ». Peut-être que sur ce type de plateforme qui tourne sous Android, Java peut vivre une seconde jeunesse.

Et vous ?
Avec quel langage vous lanceriez-vous dans l'aventure ?

Envoyer le billet « Faut-il encore adopter Java pour un client lourd ? » dans le blog Viadeo Envoyer le billet « Faut-il encore adopter Java pour un client lourd ? » dans le blog Twitter Envoyer le billet « Faut-il encore adopter Java pour un client lourd ? » dans le blog Google Envoyer le billet « Faut-il encore adopter Java pour un client lourd ? » dans le blog Facebook Envoyer le billet « Faut-il encore adopter Java pour un client lourd ? » dans le blog Digg Envoyer le billet « Faut-il encore adopter Java pour un client lourd ? » dans le blog Delicious Envoyer le billet « Faut-il encore adopter Java pour un client lourd ? » dans le blog MySpace Envoyer le billet « Faut-il encore adopter Java pour un client lourd ? » dans le blog Yahoo

Mis à jour 07/03/2016 à 10h38 par ClaudeLELOUP

Tags: java
Catégories
Sans catégorie

Commentaires

  1. Avatar de a028762
    • |
    • permalink
    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...
  2. Avatar de esperanto
    • |
    • permalink
    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.
  3. Avatar de olikaf
    • |
    • permalink
    @a028762 ,
    Pour android pas de soucis, c'est du java certes, mais l'interface utilisateur vient avec son propre framework !
  4. Avatar de Népomucène
    • |
    • permalink
    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.
  5. Avatar de crodilus
    • |
    • permalink
    Citation 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 ... ? !
  6. Avatar de I_Pnose
    • |
    • permalink
    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.
  7. Avatar de J@ckHerror
    • |
    • permalink
    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.
  8. Avatar de Saverok
    • |
    • permalink
    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.
  9. Avatar de odbo13
    • |
    • permalink
    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...
  10. Avatar de Invité
    • |
    • permalink
    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).
  11. Avatar de epsilon68
    • |
    • permalink
    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
  12. Avatar de martopioche
    • |
    • permalink
    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é ?
  13. Avatar de Jiji66
    • |
    • permalink
    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 ...
  14. Avatar de lvr
    • |
    • permalink
    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).
  15. Avatar de kilroyFR
    • |
    • permalink
    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.
  16. Avatar de lvr
    • |
    • permalink
    flag
  17. Avatar de Jitou
    • |
    • permalink
    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.