John Rose, Brian Goetz et Guy Steele ont publié un brouillon sur l'état des travaux concernant l'ajout du support des values types dans la spécification JVM et dans le langage Java. Le document, en anglais, annonce directement la couleur avec un slogan : “Codes like a class, works like an int!”, que l'on pourrait traduire par "Codé comme une classe, fonctionne comme un int". On retrouvera ce slogan plusieurs fois pour décrire certains comportements attendus des value types.
L'objectif des value types (je ne traduis volontairement pas ce terme) est de permettre aux utilisateurs de définir des aggrégats de valeurs pouvant être traités comme tels par la JVM. En effet, en dehors des huit types primitifs de Java, il n'est possible que de définir des classes, ce qui impose un surcoût non négligeable pour représenter d'autres types de valeurs, tels que des nombres complexes ou des entiers non signés. De plus, les opérations sur les classes passent par des méthodes, ce qui alourdit la syntaxe, et donc la facilité de lecture. On peut prendre comme exemple les classes BigInteger et BigDecimal.
Le support des value types permettra aussi d'améliorer de nombreux points problématiques pour l'amélioration des performances ou de la consommation de mémoire par la JVM. Par exemple, la création de tableaux optimisés du point de vue de la localité mémoire. A l'inverse d'un tableau de primitifs, qui est disposé de façon compacte en mémoire, un tableau d'objets est en fait un tableau de références vers des objets placés en heap. Le parcours d'un tableau d'objets consiste donc à accéder à de nombreux emplacements mémoire, ce qui peut impacter les performances étant donné le coût d'un cache miss. Ce phénomène est amplifié par le fait que les prefetcher des CPUs auront plus de difficulté, voire l'impossibilité de déterminer un scénario d'utilisation de la mémoire, et donc de précharger les données qui seront nécessaires. Avec une représentation compacte en mémoire, en plus de la diminution de la consommation, le parcours est linéaire et prédictible par les prefetchers.
Les value types auraient aussi une sémantique de passage par valeur, c'est à dire qu'au lieu de copier la référence vers un objet pour la passer en paramètre, ça serait une copie de la structure elle-même qui serait passée, comme pour les primitifs, ce qui permettrait encore une fois plus d'optimisations par le runtime puisque cela offre une garantie de non-partage de la valeur.
Pour atteindre ces objectifs, un certain nombre de contraintes seront placées sur les value types, comme l'immuabilité, l'impossibilité de synchroniser dessus et en particulier un comportement de la comparaison d'identité (==) qui fait une comparaison de tous les éléments et pas de la référence.
De la même manière que les types primitifs, un boxing sera ajouté par le compilateur dans le cas de l'utilisation d'un value type à la place d'un objet, la seule différence est que la classe de boxing pourra être générée par la JVM au runtime plutôt que de forcer les développeurs à l'implémenter.
Un certain nombre de questions restent en suspens, telles que les intéractions avec certains mécanismes existants comme la réflexion ou les types génériques, mais aussi la syntaxe qui sera proposée pour ajouter le support des value types au langage Java et l'intégration au bytecode, qui pourrait passer par de nouveaux bytecodes, une redéfinition de certains bytecodes ou une solution intermédiaire.
Au final, l'arrivée des value types pourrait apporter beaucoup de nouveautés à la plateforme Java, du même ordre de grandeur que l'introduction des lambdas et toutes les évolutions liées, aussi bien pour le langage Java lui-même que pour les langages alternatifs sur JVM.