D'un autre côté dans la même 7u6 ils ont discrètement balancé un autre changement nucléaire sur les String: changer l'implémentation de substring. Là le changement était permis par le contrat mais l'impact sur les applis est réel. En gros, avant un substring créait un objet qui pointait sur le byte buffer original (on partage donc la mémoire et c'est O(1)) maintenant il fait une copie du byte buffer original (on ne partage donc plus la mémoire et c'est O(n)). Le rationnel était qu'il est facile de faire des fuites mémoire par error avec l'ancienne implémentation. Maintenant tout le code qui reposait intensivement sur substring (parser etc.) à vu son profile à l'exécution bien changer.
WTF !! Mais c'est ça qui méritait un journal dénonciateur !!
Quant à leur solution à la problématique d'attaque par collisions elle me laisse un goût amer. Ils ont fortement compliqué l'implémentation de la classe de référence.
J'aurai préféré qu'ils enrichissent l'API de HashMap avec un constructeur qui permette de passer une fonction de hashage, comme TreeMap avec le Comparator. De cette manière, le développeur choisi si il veut se protéger de l'attaque ou pas.
Je dis ça mais en réfléchissant au niveau moyen du développeur java, je me dis qu'ils ont peut être raison de prendre les devants...
[^] # Re: Questions
Posté par steph1978 . En réponse au journal OpenJDK JEP 180: HashMap, collisions & attaques par la complexité. Évalué à 5.
WTF !! Mais c'est ça qui méritait un journal dénonciateur !!
Quant à leur solution à la problématique d'attaque par collisions elle me laisse un goût amer. Ils ont fortement compliqué l'implémentation de la classe de référence.
J'aurai préféré qu'ils enrichissent l'API de HashMap avec un constructeur qui permette de passer une fonction de hashage, comme TreeMap avec le Comparator. De cette manière, le développeur choisi si il veut se protéger de l'attaque ou pas.
Je dis ça mais en réfléchissant au niveau moyen du développeur java, je me dis qu'ils ont peut être raison de prendre les devants...