Discussion :

[_skip]

Merci pour ces éclaircissements. En effet si mes souvenirs sont bons les failles consernaient principalement les Applets et JWS. Ce qui n'existe pas forcément ailleurs et peut biaiser l'opinion. Mon Java est plutôt ancien. Est-ce que des vulnérabilités au niveau des EJB, pour les communication inter-applications sur plusieurs sites pourraient avoir un impact ?

Non je ne pense pas, mais là de nouveau c'est un choix d'implémentation qui détermine la sécurité. La plupart des technos de partage d'objets en Java (comme ailleurs) sont basées sur un mécanisme qui se résume à de la sérialization (binaire ou texte) et de l'envoi par socket. A compter du moment où les données qui transitent sont critiques, on va s'assurer qu'elles ne soient pas accessibles durant le transfert, soit en optant pour un protocole sécurisé (HTTPS), soit en se servant de liaisons VPN entre les sites.
C'est l'accès extérieur à la donnée qui doit être interdit, et ça AUCUN langage ne peut le garantir à la place du développeur. En java il y a tous les outils que tu veux à disposition, des implémentations de quasiment tous les protocoles, question sécurité, crypto etc... il y a tout ce que tu veux. Après si on fait le choix d'utiliser des protocoles où ça circule en clair et de laisser tes serveurs ouverts aux 4 vents, ou encore d'avaler les données envoyées par les clients sans les valider ou les authentifier, c'est pas un problème de la techno.
Même pour pousser le truc, tu as Yahoo qui a été victime il y a quelques années d'une injection SQL. Personne de censé va venir dire que c'est de la faute de PHP. Ca peut être de la négligence, de l'incompétence, tout ce qu'on veut mais c'est pas une question de langage de programmation. Personne ne dit non plus que les vols de données dans les SGBD sont de la faute du C ou C++.

Il y a un paradoxe chez moi. Oracle et Java sont reconnues comme technologies performantes et éprouvées. Et pourtant je les trouve lourdes à manipuler et poussives.
Peut-être est-ce dû à la machine virtuelle Java, qui est une aide à l'interropérabilité et l'utilisation sur tous les systèmes, mais aussi aux outils comme Eclipse que j'ai du mal à appréhender.

Je m'aperçois aussi que même si les syntaxes sont proches entre C# et Java, leur mode d'utilisation est différent. Une simple transposition de code peut entraîner de sacrés différences. Par exemple si l'appli utilise des expressions régulières, mal supportées par Java. Bref, il faut se limiter à des tests simples.

C'est une techno qui reste assez difficile à mettre en oeuvre, surtout si on la compare à PHP. Java pour le web ça doit se justifier au niveau du besoin, je n'utiliserai jamais ça pour coder mon blog perso ou un forum, ce serait vraiment tuer des moustiques au lance-roquette. Par contre pour du gros webservice à forte concurrence, c'est une autre histoire.
Je pense personnellement que le sentiment de lourdeur des applications java vient de 3 choses : l'emprunte mémoire des applications et le temps de chauffe au lancement. Quoi que de nos jours c'est moins un problème, et quand je vois ce que pompent les navigateurs webs dès qu'on a plusieurs onglets, c'est relatif. Vient ensuite la mauvaise expérience dans le monde de la GUI avec Swing et ses dessins 2D, ainsi que sa mauvaise intégration dans les environnements desktop.
Les choses pourraient s'améliorer avec la modularité en java 9 qui devrait permettre ou tout au moins ouvrir la porte à beaucoup d'optimisations dans le démarrage des applications.

PS: Pas trop envie de tomber dans le HS à répétition mais c'est la première fois que j'entends des remarques sur le support des expressions régulières en java, il me semble qu'il y a tout ce qu'on veut en ce sens...

[LSMetag]

Non je ne pense pas, mais là de nouveau c'est un choix d'implémentation qui détermine la sécurité. La plupart des technos de partage d'objets en Java (comme ailleurs) sont basées sur un mécanisme qui se résume à de la sérialization (binaire ou texte) et de l'envoi par socket. A compter du moment où les données qui transitent sont critiques, on va s'assurer qu'elles ne soient pas accessibles durant le transfert, soit en optant pour un protocole sécurisé (HTTPS), soit en se servant de liaisons VPN entre les sites.
C'est l'accès extérieur à la donnée qui doit être interdit, et ça AUCUN langage ne peut le garantir à la place du développeur. En java il y a tous les outils que tu veux à disposition, des implémentations de quasiment tous les protocoles, question sécurité, crypto etc... il y a tout ce que tu veux. Après si on fait le choix d'utiliser des protocoles où ça circule en clair et de laisser tes serveurs ouverts aux 4 vents, ou encore d'avaler les données envoyées par les clients sans les valider ou les authentifier, c'est pas un problème de la techno.
Même pour pousser le truc, tu as Yahoo qui a été victime il y a quelques années d'une injection SQL. Personne de censé va venir dire que c'est de la faute de PHP. Ca peut être de la négligence, de l'incompétence, tout ce qu'on veut mais c'est pas une question de langage de programmation. Personne ne dit non plus que les vols de données dans les SGBD sont de la faute du C ou C++.

C'est clair que la compétence du développeur est la principale cause des failles de sécurité. Mais je pense tout de même que certaines technos ont des failles intrinseques à certains niveau qui demandent de la vigilance. Je dis ça au pif mais l'implémentation d'une méthode qui par exemple pourrait créer une fuite mémoire avec des données dedans, ou créer un fichier temporaire non supprimé. Après d'autres technos comme SSL ont également révélé des failles, corrigées plus tard. Bref, il faut être attentif. HTTPS n'est plus forcément assez sécurisé.

C'est une techno qui reste assez difficile à mettre en oeuvre, surtout si on la compare à PHP. Java pour le web ça doit se justifier au niveau du besoin, je n'utiliserai jamais ça pour coder mon blog perso ou un forum, ce serait vraiment tuer des moustiques au lance-roquette. Par contre pour du gros webservice à forte concurrence, c'est une autre histoire.
Je pense personnellement que le sentiment de lourdeur des applications java vient de 3 choses : l'emprunte mémoire des applications et le temps de chauffe au lancement. Quoi que de nos jours c'est moins un problème, et quand je vois ce que pompent les navigateurs webs dès qu'on a plusieurs onglets, c'est relatif. Vient ensuite la mauvaise expérience dans le monde de la GUI avec Swing et ses dessins 2D, ainsi que sa mauvaise intégration dans les environnements desktop.
Les choses pourraient s'améliorer avec la modularité en java 9 qui devrait permettre ou tout au moins ouvrir la porte à beaucoup d'optimisations dans le démarrage des applications.

PS: Pas trop envie de tomber dans le HS à répétition mais c'est la première fois que j'entends des remarques sur le support des expressions régulières en java, il me semble qu'il y a tout ce qu'on veut en ce sens...

Il y avait aussi le fait qu'à chaque clic sur un bouton on sentait un manque de réactivité, voire un temps d'attente. Apparemment oui Java 9 a l'air de vouloir compenser les "défauts" usuels de Java, ce qui est une excellente chose. Java 8 est déjà un gros progrès. Il reprend la réécriture de Java 7 (qui supprime beaucoup de fonctions dépréciées) en corrigeant les problèmes de sécurité, et rajoute des trucs important comme les lambda expressions.

Java supporte aussi bien les expressions régulières que tout autre langage. C'est juste que les performances sur ces traitements sont mauvaises par rapport à beaucoup d'autres technologies. Ce n'est pas du HS puisque l'on parle des performances de Java et de la pertinence des benchs. C'est pour ça que la transposition d'une appli C# qui utilise pas mal les expressions régulières peut réserver des surprises niveau performances et que là il faudrait peut-être repenser la manière de développer côté Java.

[SurferIX]

Moi le seul truc que je note ce sont les langages : les meilleurs sont évidemment des langages précompilés ou pseudo compilés : Java, C, C++.
Là où cela devient intéressant c'est que parmi les langages plus haut niveau viennent en premier LUA (très intéressant) puis Python.
Php vient toujours loin, très loin derrière, si on ignore la HHVM qui transforme, justement, le Php en C++.

Très intéressant, tout ça !

[Laurent Simon]

Je pensais qu'on disait que Java côté serveur était lourd et lent à cause de la stack d'outil qu'on empilait côté serveur.

Oui, c'est tout à fait vrai, mais uniquement quand on ne sait pas s'en servir. Comme avec beaucoup d'autre langages d'ailleurs.

Empiler les frameworks est le parfait exemple de ce qu'il faut faire pour s'assurer que ce soit bien lent et que ça ne puisse pas monter en charge. Beaucoup le font. Mais ça, on est absolument pas obligé!

Quelque soit le langage, grosso-modo, les performances et la capacité de montée en charge seront toujours inversement proportionnelles à la profondeur moyenne de la stack pendant le déroulement du programme.

Attention, je ne dis pas qu'il ne faut utiliser de frameworks. Il faut juste le faire à bon escient. Toujours s'assurer que l'usage d'un framework est bien un gain réel avec un coût acceptable pour l'application. En aucun cas ça ne doit être juste un confort, une facilité ou pire, une habitude, pour le développeur.