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 !

L'Etat de Java : où en est la technologie en 2014 ?
Entretien croisé avec le CTO France, le responsable du pôle JAVA et un expert de DigitasLBi

Le , par Gordon Fowler

40PARTAGES

9  2 
NB : cet entretien est en deux parties

S'il y a une technologie de développement qui alimente les chroniques des gazettes (IT et même grand public), c'est bien Java.

Sécurité critiquée ou louée, rachat par Oracle, avantages et faiblesses de la JVM, procès Android, nouveaux frameworks, orientations prises… les sujets ne manquent pas.

À tel point qu'il nous a paru bon de prendre un peu de recul pour dresser un « État de Java », sur le modèle de l'« État de l'Union » en politique, loin du flux continu de news et de « trolls » plus ou moins argumentés qui, à la longue, aveugle.

Nous avons envisagé plusieurs options. Faire cet « État » avec Oracle, par exemple. Mais l'entreprise de Larry Ellison étant partie prenante sur toutes les questions sensibles (GlassFish, Android, mises à jour, etc.), nous avons cherché une autre option. Avec des SSII (ESN) ? L’idée nous paraissait bonne. Jusqu’à ce que nous rencontrions des développeurs de DigitasLBi.

Pourquoi ? D’abord, parce que DigitasLBi – un réseau d'agences de « digitalisation & d'innovation technologique » (6.000 experts dont 300 en France) qui gère des projets globaux pour des marques comme Nissan, eBay, American Express ou La Poste - est totalement indépendant des éditeurs (voir aussi : sa page sur Developpez.com)

Ensuite, parce que cette agence d’un nouveau genre se place à la croisée d’une multitude de chemins (beaucoup plus que les ESN). DigitasLBi fait aussi bien de la communication numérique, du design d’UI que du développement. Et dans le développement pur, l’agence touche aussi bien au web (HTML, CSS, JS) qu’au .NET ou, donc, à Java (sans oublier les bases de données). Simple exemple, DigitasLBi a pris en charge toute la communication numérique de Nissan (site web, applis mobiles, etc.)… mais va jusqu’à concevoir tout l'embarqué de ses véhicules.

Enfin - et surtout - parce que son pôle Java/JEE est un nid d'expertises. Cette équipe d’environ 40 personnes est chapeautée depuis maintenant cinq ans par Romaric Le Bever, doté d'un riche background (e-commerce, ingénieur d’études, chef de projets techniques, etc.) et dont le bras droit est un passionné diplômé de l'Ecole des Mines de Nantes. Les deux, ainsi que le CTO – Arnaud Defrenne – se sont révélés être loin de toute querelle de chapelles malgré plus d'une dizaines d'années de carrière dédiée à leur technologie de prédilection.

Dans la première partie de cet entretien nous avons abordé avec eux la popularité du langage, sa sécurité, Java 7 et Java 8, et le virage vers l’embarqué. N'hésitez pas à nous faire part de vos propres points de vue d’experts et à interagir avec eux (nous savons de source sûre qu'ils gardent un œil sur Developpez.com). La deuxième partie est ici

Developpez.com : Quatre années après son rachat par Oracle, comment se porte Java aujourd’hui ? Vous semble-t-il toujours aussi populaire en France ?

DigitasLBi : Je vous ferai une réponse influencée par ma perception de l’utilisation des technologies Java dans l’univers du marketing numérique. Cette mise en garde effectuée, il me semble que le Java se porte comme un charme. Nous assistons même à une recrudescence des projets web en Java.

Une certaine image de sécurité, fiabilité et de solidité le rend populaire auprès des entreprises industrielles et aussi banques et assurances. Enfin à l’heure où les appareils connectés mobiles se multiplient, où la diversité des systèmes d’exploitation est de mise, finalement Java est un langage de développement multi-device, multi-OS, ce qui est très précieux. Android y est aussi pour quelque chose.

Developpez.com : Certains accusent Java d’être lourd, lent et verbeux. Côté technique, comment voyez-vous le travail d’Oracle et de la communauté sur l’amélioration du langage avec l’arrivée de Java 7, et à l’aube de Java 8 ?

DigitasLBi : Java a été à l’origine conçu comme un meilleur C++ dans les années 1990, incorporant des concepts de SmallTalk, Objective-C et Ada. À cette époque, Internet était balbutiant et la plupart des technologies d’aujourd’hui n’existaient pas.

Java 7 est la reconnaissance qu’un langage unique n’est pas forcément adapté à toutes les situations, et s’est ouvert à des langages dérivés de la JVM avec l’instruction invokedynamic (qui est la 1ère nouvelle instruction JVM depuis Java 1.0 !). Oracle ne reste pas en plan, s’inspirant du meilleur des autres langages pour rendre Java plus productif — je parle ici du Project Coin incorporé à Java 7, et des lambda attendues avec impatience avec Java 8.

Bien évidemment, toute modification substantielle de Java prend du temps (et parfois beaucoup !). Mais je pense que nous avons un équilibre entre évolution et stabilité du langage, ce qui est très important dans le monde de l’entreprise.

Enfin, oui, Java est verbeux, particulièrement face à des langages comme Groovy ou Ruby. Nous supportons ici l’héritage des années 1990.

Par contre, je ne peux pas laisser dire que Java est lent ! Ce qui est lent, ce sont les algorithmes pas toujours très optimisés pondus par certains développeurs (tous langages confondus). Ce qui est lent, c’est la masse de données à traiter, en augmentation constante. Ce qui est lent, ce sont les frameworks et solutions toujours plus complexes, libérant le développeur de considérations bas niveau en cachant la complexité (gain de productivité) mais également le coût associé.

Java en lui-même est grossièrement aussi rapide que le C (ceci n’est pas un appel à troll…). Je teste régulièrement mes applications personnelles sur un vieux Pentium M (en fin de vie) de 2005 ainsi que sur un Raspberry Pi, ce qui me permet de détecter d’éventuel code non optimal.

Developpez.com : Au passage, si l’on ne devait retenir que trois nouveautés de Java 7, quelles seraient-elles ?

DigitasLBi : Je retiendrais principalement les améliorations apportées par Project Coin qui facilitent la vie quotidienne du développeur.

Java 7 a également connu depuis sa sortie en 2011 une évolution « transparente » sur la JVM (début de l’intégration Hotspot et JRockit, notamment les aspects monitoring). C’est à mon sens important pour optimiser au maximum les performances d’applications toujours plus riches.

Developpez.com : Que peut-on espérer pour Java 8 ?

DigitasLBi : Personnellement j'attends de Java 8 de substantielles améliorations tant au niveau de la JVM (continuation de la fusion de HotSpot et JRockit, même si G1 a été repoussé à Java 9) qu’au niveau de la productivité développeur (les lambda, mais également javac multi-threadé).

Malheureusement, pour certains de nos projets, nous ne pourrons passer à Java 8 que lorsque les éditeurs le supporteront officiellement !

Developpez.com : Java a été beaucoup critiqué sur ses failles de sécurité. Vous parait-il plus sûr aujourd’hui, voire très sûr, ou pensez-vous - comme le disent certains - que régler ce problème prendra encore quelques années ?

DigitasLBi : Le sujet de la sécurité est à prendre très au sérieux. La recrudescence des attaques et des piratages est une réalité. D’autre part avec le développement des applications « cloud » nous assistons à une explosions du stockage d’informations personnelles sur les réseaux. L’enjeu est donc doublement important.

Par Java on peut entendre deux choses :

- l’utilisation de Java comme langage Backend ;
- les applets Java compilées et exécutées côté client.

Les technologies utilisées en particulier en backend ont un rôle important dans la sécurisation des applications, quand on compare les différentes options, Java comme framework backend est plutôt bien placé. Néanmoins au-delà de cela, choisir un environnement ne suffit pas. Pour garantir à nos clients des applications sûres, nos propositions combinent des bons choix d’architecture avec exigences sur les processus, la documentation, la fréquence des mises à jours logiciels, et aussi certains services de sécurité qui vont simuler régulièrement des attaques pour éprouver les solutions.

Sécuriser les serveurs c’est une choses, mais côté navigateur c’est un peu plus compliqué.

Developpez.com : Sur ce sujet de la sécurité, Mozilla a désactivé tous les plug-ins par défaut de Firefox 26 (sauf Flash). Les applets Java sont au centre de cette décision. Vous parait-elle bonne ou mauvaise ?

DigitasLBi : À partir du moment où des codes dangereux se diffusent comme des virus à l’échelle de la planète c’est une décision défensive mais sage.

Nous n’utilisons pas cette technique qui tend à disparaître avec l’enrichissement du JavaScript coté client. Le véritable enjeu maintenant c’est garantir l’absence de faille en JavaScript.

Developpez.com : Ces derniers temps, Oracle met beaucoup en avant l’embarqué (Java SE Embedded, Java ME, Java Card sur les cartes à puces, Java TV pour les téléviseurs connectés et les Box, etc.) comment analysez-vous ce mouvement ?

DigitasLBi : Oui c’est le grand retour d’une des principales forces de Java : un langage qui s’exécute sur n’importe quel assembleur grâce à la machine virtuelle Java.

L’explosion du DIGITAL c’est avant tout un très grand cycle d’innovation pour les périphériques. Téléphones, baladeurs, télé numériques furent les précurseurs mais on assiste maintenant à l’exploration systématique du potentiel de connecter tous les objets de la vie de tous les jours… Une balance pour se peser (et suivre son poids avec une appli), une montre pour se localiser et courir avec ses amis, un collier qui localise son animal familier etc…

Cette formidable innovation sur le terrain des périphériques s’accompagne d’une diversité de systèmes d’exploitation très difficile à gérer !
Dans ce monde de diversité il y a une recherche pour des solutions multi-device.

Java apparaît comme une réponse pour les applications. HTML/JS une autre réponse pour les interfaces. Android est un système qu’on voit se répandre dans de nombreux appareils. D’autres systèmes open-source sont aussi très intéressants.


Publications techniques et offres d’emplois de DigitasLBi sur Developpez.com

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

Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 12/02/2014 à 13:54
Citation Envoyé par eclesia Voir le message
Java a toujours été plus qu'un simple language, avec tout un environnement. et depuis 4ans meme si Java est tres présent, il évolu globalement moins vite que sous la direction de Sun, il y avait plus de création et d'innovation. parmis les projets dont on entend parler, javafx, coin, lambda etc... tout cela on en entend parler depuis bien plus de 4 ans.
Ce n'était pas forcément mieux du temps de Sun...

Avant Java 5.0, la plus grosse modif du langage concernait les classes internes dans Java 1.1, puis des mots-clefs strictfp et assert dans Java 1.2 et 1.4. Et c'est tout !
Il aura fallut attendre 8 ans pour que Java 5.0 apporte un vent de fraicheur au langage...

Et même là les "nouveautés" étaient discuté depuis bien longtemps.
La JSR sur les Generics a débuté en 1999 alors que Java 1.3 n'était pas encore sorti... et que Java 5.0 est arrivée en 2004 !

Quand à Java 7, il peut paraitre anodin en substance, mais il cache en son sein l'une des plus grosse modif de Java : l'ajout de l'instruction invokedynamic dans le bytecode.
D'ailleurs l'implémentation des lambdas de Java 8 est fortement basé là dessus.

Pour avoir suivi pendant un moment certaines mailings list (coin et lambda en particulier), il y a une attention très particulier porté aux impacts de chaque nouvelle fonctionnalités, ainsi qu'à leurs fonctionnements et les éventuels problèmes que cela peut entrainer.

Il en résulte un processus bien plus long, mais peut-être aussi un peu plus réfléchi et un peu moins "fashion victim".
On compare souvent Java à C#, mais même si les fonctionnalités semblent similaire, il prend bien souvent une direction et une approche différente?
Par exemple :
  • Les enums qui sont de vrai objets (avec des attributs/méthodes) pouvant implémenter des interfaces.
  • La covariance/contravariance des Generics utilisable au besoin sur n'importe quel type Generics, alors qu'il faut définir un type précis avec C#.
  • Les lambdas qui s'affecte dans une interface fonctionnelle au lieu d'utiliser un type spécifique.
  • Les default's methods intégré au runtime, qui permet de profiter quand même des bénéfices de l'héritage.


a++
7  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 12/02/2014 à 16:04
Ca fait plaisir de lire un article assez objectif sur Java sans parti pris.
Merci developpez.com !!

Pour ce qui est des performances, je suis en total accord avec les experts de DigitasLBi.
Je ne compte plus les fois où j'ai dû repasser sur du code non optimisé avec une gestion de la mémoire absolument désastreuse...

Pour ce qui est du côté verbeux, personnellement, je trouve ça très bien.
Ca rend le code parfaitement lisible et compréhensible qui peut alors être facilement repris et maintenu : essentiel pour des applications d'entreprise.

De mon point de vu, un bon développeur est un développeur qui sait trouver l'équilibre entre perf et lisibilité.
Car si tu codes quelques d'ultra performant mais tellement complexe et illisible que personne d'autre ne pourra le reprendre, celui ne sera jamais utilisé.
L'inverse est tout aussi vrai.
Java est un excellent langage pour gérer ces 2 aspects du développement.
4  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 11/02/2014 à 18:43
Je ne suis pas du tout convaincu.
Je travail en java et en .net, niveau web ça se vaut mais coté client lourds ,
je suis plus productif en .net.

LA multitude de framework JAVA est intéressante technologiquement mais ça deviens rapidement bordélique.
6  3 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 15/02/2014 à 15:59
Bonjour,

la portabilité à un avantage là où on ne l'attends pas.

ma MOA a des exigences très strictes. l'une d'elle est que les livrables ne soit pas modifiés durant le passage de la phase DEV à la PROD.
nous avons les étapes suivantes
DEV => ASSEMBLY => QUALIF => INTEG TECH => RECETTE => PRE PROD => PROD.
Le dev pour des raison de coût se fait sur des PC xp (32 bits)
chaque developpeur à son environnement en local.
Il peut à la demande déployer sur la plateforme ASSEMBLY ou il peux alors tester que son DEV s'assemble bien avec les composants des voisins.
Déjà ces deux espaces ont un changement majeur 32/64 bits pour la JVM

Lorsque le DEV est passé l'intégration continue produit un version RC la QUALIF vérifie quelle est conforme
LORSQUE cela est le cas on produit une Release.

à partir de là la MOA est stricte il est interdit de modifier 1 bit du livrable.
Elle passe à l'INTEG TECH qui à pour but que techniquement le livrable s'intégrera à l'environnement cible.
ensuite vient la Recette qui fait que des test fonctionnel et la preprod puis la prod.

là encore pour des raisons de coût les environnements ne sont pas tous identiques.

si nous étions en C++ ou en C le passage d'une plateforme à l'autre impliquerait une recompilation (Pa-Risc, X86, IA64, arm etc...). ma MOA refuserait alors le produit. où alors il faudrait que toute les plateformes soit à l'identique de la cible finale. si vous avez lu mes messages vous aurez comprit que ce coût serait exorbitant.

Donc finalement le fait que Java offre une portabilité est un gain non pas parce que l'application est destiné à être utilisée sur des machines différentes mais pour réduire les coûts.

Dans les SI la portabilité de Java est très appréciée là encore non pas parce que les applis doivent être utilisé sur des environnement hétérogène, mais parce que c'est une contrainte de moins à long terme.

Maintenir une machine capable de faire tourner une application développé en Cobol en 1968 est une contrainte très forte. savoir que l'application qu'on déploie aujourd'hui et qui à des chance d'être encore là dans 20ans ne bloquera pas l'évolution de l'infrastructure est pas un simple plus c'est un énorme gain de coût.

Cela à des limites bien sur mais la portabilité de Java réduit ces contraintes donc les coût.

A+JYT
3  0 
Avatar de atha2
Membre éprouvé https://www.developpez.com
Le 12/02/2014 à 21:51
Citation Envoyé par super_navide Voir le message
Je pense la seul chose qui manque qui devrait faire l'objet d'un JSR , c l'ajout de type structure et tableau comme en c pour alloué des données sur la pile d'execution.
Cela permetrait d'éviter d'utiliser le GC, a d'avoir des fonctions rapide pour manipuler des vecteurs des matrices etc...
Et surtout le langage pour servir pour des applications de bas niveaux comme des drivers etc...
Sinon Lejos (programmation java sur la LEGO NXT ) est un bon example du standard qu'est JAVA et de ca puissance
Pour information, maintenant (depuis java 6u23) la JVM applique l'Escape Analysis (http://docs.oracle.com/javase/7/docs...escapeAnalysis, https://weblogs.java.net/blog/forax/...alysis-default). Pour faire simple, si elle le peut (ou l'estime avantageux), la JVM va allouer les objets dans la pile. Par exemple un objet dans la portée est limitée à une seule méthode sera surement alloué sur la pile.
2  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 14/02/2014 à 17:41
Citation Envoyé par plawyx Voir le message
C'est pour ça que je ne comprends pas cette réputation de lenteur qui lui colle à la peau.
Les idées reçues ont la vie dure... tout simplement.

La réputation vient de plusieurs éléments :
  • Dans les premières versions de Java, le bytecode était interprété ce qui ne donnait effectivement pas de grosses performances.
    Toutefois ce n'est plus le cas depuis 1998 et Java 1.2... mais l'idée de base reste présente dans les esprits.
  • J'ai vu trainer sur le web des "astuces" pour optimiser le code Java qui datait de cette époque... mais qui n'avait plus lieu d'être !
    Elles ont pourtant perdurer pendant longtemps en continuant l'idée de "Java c'est lent" donc il faut optimiser à tout prix...
  • Certains mécanismes sont très différents du C/C++, et en voulant comparer ou porter des codes C/C++, ou même en voulant "optimiser" son code car "Java c'est lent" on peut être amener à faire involontairement des choses incorrects en Java qui peuvent s'avérer catastrophique en terme de performances.

    L'inverse est aussi vrai : on peut faire quelque chose de catastrophique en C/C++.

    Toutefois ces derniers ne souffraient pas de cette image, et en cas de mauvaise perfs on remettait en cause l'algo et le code plutôt que le langage.
    Avec Java c'était plus facile de reporter le problème sur le langage ou la plateforme...
  • AWT/Swing et les applets ont sûrement aussi fait beaucoup pour cela.
    Non pas que la techno soit mauvaise, mais plutôt car elle nécessite certaines connaissances (comme la gestion de l'EDT).
    Toutefois ces concepts n'était pas forcément bien documenter ou mis en avant, ni forcément simple à appréhender !
    Du coup on pouvait voir des programmes qui effectuaient toutes sorte de tâche dans l'EDT, ce qui a pour résultat de geler l'interface graphique et donc une grosse impression de "lourdeur".

    Mais c'est la méconnaissance du fonctionnement de ces technos qui entrainait cela...

    C'est aussi un peu la faute de Sun : l'API manquait de solution "simple" pour gérer cela.
    Par exemple si Swing est arrivé en standard dès 1998 avec Java 1.2, il faudra attendre 2006 et Java 6 pour que la classe SwingWorker soit intégré dans l'API.
    Avant cela il fallait la rechercher au fin fond d'un tutoriel pour la copier/coller... et il me semble même qu'il y avait plusieurs versions différentes plus ou moins complète...

    Encore maintenant il s'agit de notion pas forcément bien mis en avant...


a++
2  0 
Avatar de Robin56
Responsable Java https://www.developpez.com
Le 11/02/2014 à 23:01
Citation Envoyé par Johnny P. Voir le message
Par exemple côté client lourd à mon sens on devrait plus utiliser swing et d'autre UI vieux d'une dizaine d'année et surtout pas adapter à aujourd'hui mais plutôt passer à JavaFX qui est une merveilleuse technologie pour la création d'UI et qui offre ce que le .NET fait depuis des années avec le WPF.
Ça doit dépendre des domaines mais pour ma part, ça fait un moment que je n'ai pas vu une application professionnelle en Swing. Tout ce qui est application complexe qui reste client lourd tend à se faire en Eclipse RCP. Pour les autres, elles se tournent de plus en plus vers le full web.

Je ne sais donc pas si c'est du au fait que les applications tendent à se centraliser (et avec le web c'est plus pratique), que les gens ont une méconnaissance des nouveautés (JavaFX en est un exemple flagrant) ou que ce genre de technologie est boudé pour une autre raison.

Citation Envoyé par Johnny P.
C'est justement le problème dans l'univers Java , tant que ton application fonctionne , le reste ça importe peu...
Que veux tu dire par là ?
2  1 
Avatar de professeur shadoko
Membre expérimenté https://www.developpez.com
Le 12/02/2014 à 12:23
je bosse uniquement en JavaSE sur un projet scientifique avec des tas d'aspects critiques.
L'accusation de verbosité me fait marrer: heureusement que Java est verbeux! dans un équipe avec des programmeurs éparpillés à différents endroits de la planête il vaut mieux être extrèmement explicite.
Certes j'utilise Groovy pour des maquettes et des scripts mais pas pour des runtime critiques.

Je développe des éléments de framework ... mais aussi j'utilise d'autres framework et là il faut être très vigilant sur les aspects maintenabilité et durabilité des autres frameworks
citation : Maven + Spring + JBoss + AspectJ + JUnit (ou son successeur) + Log4J +
Maven: m'empoisonne la vie mais j'ai pas le choix
AspectJ: utilisé au début ... mais en sommeil
JBoss: était utilisé uniquement pour un besoin ponctuel : JMS -> remplacement par communication JGroups
Spring: éliminé ...j'ai re-écrit cette partie de framework (trop fragile pour ce que l'on fait)
JUnit: éliminé et remplacé par notre propre framework de test (je n'ai jamais compris pourquoi Junit est un "standard": les sources ne sont même pas documentées sérieusement et les fonctionnalités sont bancales)
Log4J: pour des besoins particuliers de logging j'ai voulu faire ma propre librairie ... mais là je me suis planté car la librairie standard de Java (JUL) est un vrai caca de programmation (je m'en suis rendu compte trop tard) ... comme quoi on n'est pas toujours gagnant en s'imaginant être plus astucieux que les autres

moralité: dans un milieu où Python est le langage dominant ... je suis bien content d'avoir Java! Après c'est vrai que le choix des bibliothèques sur lesquelles s'appuyer est un vrai casse-tête stratégique.
1  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 12/02/2014 à 13:07
Je pense la seul chose qui manque qui devrait faire l'objet d'un JSR , c l'ajout de type structure et tableau comme en c pour alloué des données sur la pile d'execution.
Cela permetrait d'éviter d'utiliser le GC, a d'avoir des fonctions rapide pour manipuler des vecteurs des matrices etc...
structure et tableau ?
Considérons que les structures existent, qu'ils sont l'équivalent des "class", qui passent par copie.
Une structure ne pourra donc contenir que des attributs avec des variables primitives, vu que le garbage Collector gère les classes créées avec le mot-clé class. Je trouve ça très limité.
Un tableau en C ou C++ ne passe pas par copie, donc tu dois le gérer toi même si tu l'alloues dynamiquement
Conclusion tu remets en cause Java de A à Z. Autant gérer la mémoire manuellement, donc rester sur du C ou C++ (ou utiliser les smart pointers en C++, qui je trouve sont lourd à l'écriture).
1  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 14/02/2014 à 16:26
Bonjour.

J'utilise Java dans un contexte un peu particulier probablement.

Pas de traitement lourd (algos simples courts, de petits objets)
Pas d'iHM

Mais de très très nombreux objets.
je travaille dans le monde hospitalier
Ce sont 5 millions de consultations externes.
1,2 million de séjours
1,1 million d'urgences
Bref vous aurez compris qu'il y a beaucoup de choses qui passent par nos les outils.

Et je dois dire qu’indéniablement la qualité du développement change la donne.
Nous avions une solution déployée partiellement (40 établissements pour la gestion logistique et comptable. Un seul, pour la gestion de l'activité médicale).
Pour la gestion logistique nous avons été obligés de dédier une machine virtuelle pour la gestion des livraisons. De nombreuses lenteurs, beaucoup d'indisponibilité du système.

Vous m'auriez demandé à cette époque si Java était lent, je pense que je n'aurais pas eu la même réponse qu'aujourd'hui.
Bref, nous avons tout revu. Nous avons changé de solution. Mais nous sommes restés à Java. Et, aujourd'hui l'ensemble fonctionne sur 4 coeurs pa-risc. Malgré l'énorme volumétrie traitée par notre système, la latence du système se mesure en secondes. Lorsqu’aujourd'hui on constate une latence de 10s, tout le monde s'alerte. Les points faibles de la solution sont les entrées/sortie. L’usage du processeur et quasi négligeable.
Je suis toujours impressionné par la réactivité du système. Nous avons des dizaines de milliers de threads. Plutôt que des algos longs et complexes, nous avons opté pour des traitements courts, simples, et nombreux, qui communiquent entre eux de façon asynchrone. Le système reste pourtant très vif.

Si je faisais une comparaison, je dirais que nous sommes passés d'un camion des années 60 sur une route de haute montagne à un TGV. Pourtant nous n'avons pas changé de machine physique, nous avons diminué notre impact mémoire, nous avons supprimé des moteurs, nous n'avons pas changé de JVM.

Alors je ne sais pas si Java est lent ou rapide. Je ne sais pas si on peut affirmer que cette assertion est due à de mauvais développements. Mais mon expérience m'a montré que de mauvaises solutions peuvent avoir des résultats plus que catastrophiques. Après une longue carrière, je m'attendais à un gain de perf, mais je n'avais pas imaginé de telles proportions.

Pour ce qui est de l'évolution de Java je pense qu'il y a effectivement un gros héritage du modèle objet des années 1990.
Pour moi, Java souffrait d'un manque de clarté. Java c'est la JVM, le langage, et la Lib standard. Et pendant trop longtemps, on a considéré tout cela de façon monolithique.

Au fil du temps et en fonction des modes, on a vu la Lib Java gonfler comme un zeppelin. Le langage n'a quasiment pas changé. Et la JVM n'a subi que des améliorations techniques. Certaines très importantes.

Je pense que Java a pris un tournant il y a quelque temps.

La JVM est devenue un environnement d'exécution qui s'affranchit du langage. Pour la première fois depuis la version 1 une nouvelle instruction est apparue. Imaginez le processeur X86 13 ans sans aucune nouveauté.

Le langage en lui-même connait lui aussi une révolution en intégrant des technos des années 70 (lambda) et quelques éléments plus récents.

La Lib, elle a un gros travail et c'est toujours là que le bât blesse. Elle est devenue incohérente, lourde et redondante. Il y a bien eu une volonté de tout réorganiser. Mais nombre d'acteurs ne sont pas prêts à une rupture. Pourtant je pense qu'elle est inévitable.

Personnellement, j'aimerais voir arriver quelques changements. En premier lieu, supprimer définitivement les types primitifs qui ne servent à rien (char, int, long, bool et array). Java serait enfin tout objet.
Je supprimerais bien toutes les java IO historiques pour ne garder que des objets en nombre réduit.
Je verrais bien Java épuré des centaines de collections, en tout genre. Il y en a tellement que la plupart des développeurs n'en connaissent que 10% et utilisent toujours les 2 ou 3 même.
Je verrais bien une notion de profil comme cela avait été envisagé. Définissant des groupes de capacités permettant de n'avoir plus qu'un seul Java et non plus les JME et autre bidules.

J'aimerais une API permettant de savoir ce dont est capable la JVM. Plutôt que de jouer avec les classes présentes dans le ClassLoader. Couplé avec la notion de profil, pouvoir demander à sa JVM si elle gère l'affichage, le réseau, les ejb, etc. on trouve ça dans les environnements d'exécution normalisés proposant de la modularité.

Bref je pense qu'il a beaucoup à faire.
A+JYT
1  0