Faut-il encore adopter Java pour un client lourd ?
Avec quel langage vous lanceriez-vous ?

Le , par autran, Rédacteur
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster un commentaire

Avatar de a028762 a028762 - Membre confirmé https://www.developpez.com
le 07/03/2016 à 10:09
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...
Avatar de esperanto esperanto - Membre confirmé https://www.developpez.com
le 07/03/2016 à 10:16
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.
Avatar de olikaf olikaf - Nouveau membre du Club https://www.developpez.com
le 07/03/2016 à 10:37
@a028762 ,
Pour android pas de soucis, c'est du java certes, mais l'interface utilisateur vient avec son propre framework !
Avatar de Népomucène Népomucène - Modérateur https://www.developpez.com
le 07/03/2016 à 11:48
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.
Avatar de crodilus crodilus - Membre régulier https://www.developpez.com
le 07/03/2016 à 13:08
Citation Envoyé par Népomucène Voir le message
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 ... ? !
Avatar de I_Pnose I_Pnose - Membre chevronné https://www.developpez.com
le 07/03/2016 à 15:54
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.
Avatar de J@ckHerror J@ckHerror - Membre expérimenté https://www.developpez.com
le 07/03/2016 à 16:13
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.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 07/03/2016 à 18:18
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.
Avatar de odbo13 odbo13 - Membre à l'essai https://www.developpez.com
le 07/03/2016 à 19:51
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...
Avatar de Squeak Squeak - Membre actif https://www.developpez.com
le 07/03/2016 à 20:09
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).
Contacter le responsable de la rubrique Accueil