L'ingénieur logiciel Paul Sandoz d'Oracle a posté un message sur la liste de diffusion d'OpenJDK et envoyé un tweet la semaine dernière demandant au public son opinion sur la classe sun.misc.Unsafe en répondant à un sondage Survey Monkey. Le débat tourne autour de la question de la standardisation de certaines parties d'Unsafe. La classe soumise à controverse est sous surveillance en raison de sa divergence par rapport au crédo Java de gestion sûre de la mémoire. La classe sun.misc.Unsafe pssède plus de 100 méthodes, dans des domaines divers tels que la synchronisation, l'accès direct à la mémoire, la manipulation des objets et leurs propriétés, ainsi que d'autres catégories antithétiques à la gestion sans risque de la mémoire. Certaines de ces méthodes comme les lectures et écritures volatiles, les écritures ordonnées et les opérations de compare-and-swap sont très utilisées dans le package java.util.concurrent. D'après la javadoc, Unsafe contient "une collection de méthodes pour effectuer des opérations de bas niveau non sûres. Bien que la classe et toutes les méthodes soient publiques, l'utilisation de cette classe est limitée puisque seul du code autorisé peut en obtenir une instance". Un article de Mykhailo Kozik propose un "tour d'horizon rapide de l'API publique de sun.misc.Unsafe et quelques cas d'usage intéressants".
Les questions du sondage sont :
- Avez-vous déjà utilisé la classe
sun.misc.Unsafe? - Pour quels projets avez vous utilisé Unsafe ?
- Quelles méthodes d'Unsafe avez vous utilisé ?
- Pour quelles raisons avez vous utilisé Unsafe ? Les choix proposés sont :
- Accès atomique à des champs ou des éléments de tableaux (par exemple compare-and-swap)
- Des opérations mémoire en dehors de la heap (par exemple pour émuler des structures ou des objets compacts)
- Des hacks de désérialisation
- Des barrières (pour forcer l'ordre des opérations mémoire)
- Accès aux champs privés d'une autre classe
- Accès à un tableau sans vérification des bornes
- Autre (préciser)
- Quelles fonctionnalités manquent à Unsafe ?
- Avez-vous une dépendance optionnelle sur Unsafe pour assurer que le code est portable sur d'autres plateformes Java ?
- S'il y avait un standard multi plateforme alternatif de "safe Unsafe" (Unsafe sûr) pour vos cas d'utilisation (peut-être une nouvelle API, des changements du langage ou les deux) seriez-vous prêt à remplacer Unsafe par cette alternative ? Si oui, sous quelles conditions ?
En plus de solliciter la communauté pour mesurer les usages, Sandoz annonce qu'Oracle prévoit aussi de "fouiller dans les repos". Le monde de la faible latence semble particulièrement intéressé par le sujet. Peter Lawrey est Principal Consultant à Higher Frequency Trading Ltd. et le principal développeur des librairies basse latence OpenHFT libraries. Il a déclaré à InfoQ :
Bien qu'Unsafe devrait être caché de la plupart des développeurs et du code, il fournit des accès bas niveau et thread safe à la mémoire particulièrement utiles qui sont plus efficaces que des appels JNI. i.e. Il n'y a pas d'autre façon de faire que ce que fait Unsafe efficacement. Ce dont nous avons besoin est d'un remplaçant qui soit standard parmi les JVMs et puisse être étendu pour de nouvelles technologies telles que Hardware Transaction Memory (mémoire transactionnelle matérielle) e.g. Intel TSX.
Ben Cotton, un membre actif du groupe Mechanical Sympathy, a lui déclaré à InfoQ :
Le FUD (et, honnêtement, le sectarisme technique) apparait quand le seul chemin pour gérer la mémoire finement est exposé par un package nommé
Unsafe. Comme proposé par les JEPs pour Off-Heap et FFI (Foreign Function Interface), débarrassons nous de ce nom horrible et à la place promouvons l'utilisation de ce package plus sûr comme un moyen pour résoudre d'importants problèmes de performance en Java.
Christoph Engelbert, Solution Architect à Hazelcast, le fournisseur de la populaire grille de données en mémoire open source, à déclaré à InfoQ :
Une API publique avec l'ensemble des fonctionnalités de sun.misc.Unsafe serait pour Java 9 ce que les Lambdas sont pour Java 8 - pas autant utilisé mais tout aussi important. Apache DirectMemory et Lightning mais aussi Hazelcast utilisent beaucoup sun.misc.Unsafe pour accélérer la sérialisation, les accès mémoires et diminuer la pression sur le Garbage Collector (avec des structures de données off heap). C'est une fonctionnalité fondamentale !
D'après Sandoz, le sondage sera fermé le 7 février 2014.