Discussion :

[Arsene Newman]

Projet Valhalla : un incubateur d'évolutions pour préparer le terrain pour Java 10
alors que Java 9 n’est pas attendu avant 2016

Alors que Java 8 est sorti en mars dernier et que la prochaine version majeure n’est pas attendue avant 2016, un comité d’experts dirigé par Brian Goetz vient de voir le jour pour dresser les grandes lignes de Java 10.

L’idée derrière ce nouveau projet dénommé Valhalla est de servir d’incubateur pour la version 10 de Java, en testant différentes évolutions possibles parmi les fonctionnalités qui doivent être supportées par le langage de programmation sur le long terme.

Parmi les fonctionnalités et les idées d’améliorations qui seront étudiées par le projet, il est possible de citer les valeurs des types (Value Types), ce qui peut permettre une optimisation de la représentation mémoire des types tout en maintenant les mêmes performances. D’autres fonctionnalités sont aussi à l’étude, c’est le cas par exemple de la spécialisation des génériques (Generic Specialization) ainsi que l’amélioration des volatiles (enhanced volatiles).

Le projet Valhalla tente aussi d’améliorer le langage Java en l’affectant à différents niveaux, comme le typage, le langage, la machine virtuelle ou les bibliothèques. Le projet a pour vocation de définir une sémantique claire au niveau de la machine virtuelle pour permettre un support égale pour le langage Java et les autres langages recourant à la JVM.

Pour l’heure le projet n'en est encore qu'à ses balbutiements. L’annonce de sa création a été faite via la mailing list d’OpenJDK. Elle mentionne, entre autres, les membres du comité d’experts pilotant le projet ainsi que la version de base de Java qui sera utilisée (JDK9).

Source : annonce du projet Valhalla

Et vous ?

Qu’en pensez-vous ?

[Traroth2]

Jigsaw repoussé pour Java 10 dans 5... 4... 3...

[tomlev]

les valeurs des types (Value Types)

En français on appelle plutôt ça les types valeur (par opposition aux types référence). C'est ce qui correspond aux struct de C# par exemple (ça doit aussi exister dans d'autres langages ; il me semble que Swift a aussi une notion de type valeur)

[la.lune]

Jigsaw repoussé pour Java 10 dans 5... 4... 3...

S'il n y a pas de Jigsaw dans Java 9 que ce qu'il y aura vraiment dedans

[Asmodan]

Nous espérons des optimisations de performances et corrections de bugs

[Hinault Romaric]

Java : le projet Valhalla validé par Oracle
pour préparer le terrain aux futures évolutions de la plateforme

Le projet Valhalla pour la plateforme Java prend forme. Annoncé il y a quelques mois par Brian Goetz, responsable du projet, celui-ci a été validé par Oracle.

Le projet Valhalla est une sorte d’incubateur pour le développement des futures fonctionnalités de la plateforme Java. Celui-ci va tenter d’améliorer le langage Java en l’affectant à différents niveaux, comme le typage, le langage, la machine virtuelle ou les bibliothèques. Le projet a pour vocation de définir une sémantique claire au niveau de la machine virtuelle pour permettre un support égal pour le langage Java et les autres langages recourant à la JVM.

La révision majeure dans la description actuelle du projet concerne les génériques. Les versions actuelles de Java ne permettent pas que les types génériques contiennent les types primitifs, et le compilateur Java supprime les détails du type contenu lors de la compilation. Cette approche de typage générique (effacement de type) représente l’un des aspects assez critiqués du système de types de Java.

Le projet Valhalla explorera une nouvelle approche pour la gestion des types génériques, et espère produire une nouvelle forme de typage générique, qui permettra aux développeurs d’appliquer des génériques aux types primitifs. Ainsi, dans les futures versions de Java, des déclarations telles que List<int> pourront être valides en Java.

D’autres modifications importantes sont également au menu comme les types valeurs, qui permettront une optimisation de la représentation mémoire des types tout en maintenant les mêmes performances. Les types valeurs auront pour objectif de combiner certaines propriétés des types primitifs et des types objets, pour donner naissance à un nouveau type, qui sera manipulé par le développeur comme un type primitif.

Les développeurs intéressés par le projet peuvent rejoindre sa liste de diffusion sur le site d’OpenJDK. Brian Goetz a souligné dans l’annonce que le projet est encore à un stade embryonnaire, donc la communauté ne devrait pas s’attendre à trouver une technologie développée au sein de Valhalla dans JDK 9, dont la version finale est prévue pour 2016.

Annonce du projet projet Valhalla

Description du projet Valhalla

[super_navide]

Avec cette nouveauté :
D’autres modifications importantes sont également au menu comme les types valeurs, qui permettront une optimisation de la représentation mémoire des types tout en maintenant les mêmes performances. Les types valeurs auront pour objectif de combiner certaines propriétés des types primitifs et des types objets, pour donner naissance à un nouveau type, qui sera manipulé par le développeur comme un type primitif.

On peut dire adieu au C++ le point faible de java était ne pas pouvoire définir des types primtif comme les points et autre structure pour éviter d’allouer de la mémoire.
reste plus qu'a pouvoir surcharger les opérateurs comme + - / etc..
et on pourra écrire de jolie addition de vecteur V+U aussi rapide qu'en C++.

[Thyxx]

On peut dire adieu au C++

Mais tout à fait...

[tomlev]

reste plus qu'a pouvoir surcharger les opérateurs comme + - / etc..

Bah dans ce cas tu peux faire du C#, qui fait tout ce que fait Java, a des types valeur et permet la surcharge d'opérateurs

(bah oui, je prêche pour ma paroisse, hein )

[benjani13]

On peut dire adieu au C++ le point faible de java était ne pas pouvoire définir des types primtif comme les points et autre structure pour éviter d’allouer de la mémoire.
reste plus qu'a pouvoir surcharger les opérateurs comme + - / etc..
et on pourra écrire de jolie addition de vecteur V+U aussi rapide qu'en C++.

Si les features du C++ t'interesse, pourquoi ne fais tu pas du C++ au lieu d'attendre que Java implémente ces features? Vous trouvez pas que c'est paradoxal? (le premier qui me répond "c'est pas faux" ).

Bah dans ce cas tu peux faire du C#, qui fait tout ce que fait Java, a des types valeur et permet la surcharge d'opérateurs

(bah oui, je prêche pour ma paroisse, hein )

+1

C#

[professeur shadoko]

reste plus qu'a pouvoir surcharger les opérateurs comme + - / etc..

la surcharge d'opérateur a été refusée par l'équipe initiale de java pour éviter une confusion à la lecture du code.
Un des points fondamentaux de la philosophie initiale était: ce qui est compilé est ce qui est explicitement écrit ... malheureusement des évolutions ultérieures ont un peu contourné cette règle
mais la surcharge d'opérateur rend la lecture des codes C++ incroyablement difficile , et les programmeurs en abusent en violant allégrement la sémantique de l'opérateur.... vade retro satanas ...
(quoiqu'en Scala il y a un point de vue plus amusant sur la question, voir aussi en Groovy ... mais en Java j'espère que cette demande n'aboutira jamais )
edit: C# c'est la philosophie Microsoft: vous en voulez? alors en voilà! Peu importe si ça abouti à des formalismes peu en accord avec les règles du génie Logiciel (ou à des incohérences: je pense ici à la vision Microsoft de SQL qui donne un sens à des expressions illégales parce que les utilisateurs font souvent l'erreur ... alors ils donnent un sens à ce qui n'en a pas!)

[super_navide]

et les programmeurs en abusent en violant allégrement la sémantique de l'opérateur.... vade retro satanas ...

Quel sémanatique de l'opérateur le symbol multiplication en math est utilisé pour les matrices et pour les nombre et ca sémantique n'est pas la même
sur les matrice ils perd la commutativité et la transitivité.
Donc le viol de sémantique n'existe pas.
encore une regle stupide que certain informaticien ce donne................

[Gugelhupf]

Bonjour,

J'ai lu la JEP 193 concernant l'évolution de "volatile" mais je n'ai pas tout à fait saisi l'objectif de ".volatile".

Est-ce qu'en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
// Exemple de la JEP
class Usage {
    volatile int count;
    int incrementCount() {
        return count.volatile.incrementAndGet();
    }
}

L'idée c'est de faire quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class Usage {
    volatile int count;
    int incrementCount() {
        synchronized {
            return count.incrementAndGet();
        }
 
        return 0;
    }
}

?

Merci

[_skip]

la surcharge d'opérateur a été refusée par l'équipe initiale de java pour éviter une confusion à la lecture du code.
Un des points fondamentaux de la philosophie initiale était: ce qui est compilé est ce qui est explicitement écrit ... malheureusement des évolutions ultérieures ont un peu contourné cette règle
mais la surcharge d'opérateur rend la lecture des codes C++ incroyablement difficile , et les programmeurs en abusent en violant allégrement la sémantique de l'opérateur.... vade retro satanas ...
(quoiqu'en Scala il y a un point de vue plus amusant sur la question, voir aussi en Groovy ... mais en Java j'espère que cette demande n'aboutira jamais )

Quel est ce point de vue plus amusant en Scala?
Ceci? http://www.scala-graph.org/guides/co...tializing.html
Je plaisante, si j'étais prof je crois que j'imprimerai cette doc sur du papier rouge et je l'encadrerai pour montrer aux élèves où ça peut conduire d'avoir aucune limite à sa créativité. J'arrive pas à croire qu'on puisse écrire une librairie avec autant de ****** de symboles et la destiner à un autre être humain .

Enfin pour en venir à mon vrai point sur la question, c'est de savoir si une feature doit ou doit pas faire partie d'un langage sous peine qu'elle soit mal utilisée, ou abusée. Je pense qu'à un moment donné j'étais persuadé que le plus était le mieux et que les gens n'avaient qu'à faire attention, autant depuis que j'ai vu scala (enfin même avant en fait mais mes anticorps ont surtout commencé à grossir avec scala) j'ai l'impression que tout laisser faire est une mauvaise idée.
Même si on a une avalanche de possibilités avec les features d'un langage, on peut toujours écrire du code clean, y'a des gens qui savent écrire du bon Perl, du bon scala, du bon C++, du bon java, bref. Le problème c'est qu'on va forcément à un moment ou à un autre avoir besoin de lire du code qu'on a pas écrit, c'est rare de créer une application seul et sans librairies de nos jours. Et là plus le langage permet d'écrire n'importe quoi, plus on risque de se retrouver à lire du n'importe quoi. Et on en passe du temps à lire du code dans ce métier....

[the Hound]

On peut dire adieu au C++

JAMAIS !!!
(bah oui, je prêche aussi pour ma paroisse m'voyez !)

le point faible de java était ne pas pouvoire définir des types primtif comme les points et autre structure pour éviter d’allouer de la mémoire.

Ah bon ? C'est là le seul point faible ?

[rt15]

Ah bon ? C'est là le seul point faible ?

En tout cas cela peut probablement grandement améliorer les perfs du java.

La représentation mémoire de certaines structures était certainement un vaste gaspillage.

Par exemple, a l'heure actuelle, une liste d'une centaine d'instances de points :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public class Point
{
  private int x;
  private int y;
}

devait être stockée sous la forme d'une centaine d'objets (Les objets techniques de la liste dont un tableau, plus les 100 points). Car en mémoire, on avait globalement un tableau de référence vers des objets points.

A l'avenir, on peut espérer avoir que quelques objets, et un vrai tableau de points (Le tableau de références devient un tableau des instances de points).

Les gains, tant sur la mémoire que sur sur la consommation CPU peuvent être très importants. Gains sur la CPU car on évite des centaines d'allocations couteuses même en java, mais aussi sur les traitements telles que les parcours qui vont être plus rapides.
Par contre on risque des coûts de copies si on ne fait pas attention bien sûr : quand on trie par exemple, on risque de ne plus déplacer juste les références mais les instances qui peuvent être plus grosses.

Donc oui, java rattraperait un gros point faible si ce n'est le plus gros qu'il traine depuis longtemps.

[Amine Horseman]

Java : une piste intéressante pour améliorer les types génériques
Un prototype de la « generic specialization » en cours de développement

Même si Java 9 n’est pas encore prêt, une équipe de développeurs est chargée de préparer les nouvelles fonctionnalités de la version 10. Annoncé en juillet dernier, le projet Valhalla, dirigé par Brian Goetz, a pour but d’étudier et tester ces nouvelles fonctionnalités dont la publication est prévue pour 2016.

Il y a quelques jours, Goetz publia un document où il présente l’état d’avancement concernant la gestion des types génériques, l’une des caractéristiques les plus critiquées du Java puisqu’il n’est pas possible, actuellement, d’appliquer des génériques aux types primitifs.

Étant donné qu’Oracle accorde une importance primordiale à la compatibilité avec les versions précédentes, le problème soulevé de par l’introduction d’un tel système de « génériques améliorés » doit être approché avec prudence. En effet, la difficulté est que le « système de types du langage Java n'a pas de racine unifiée », il n'y a pas de type en Java qui est à la fois un super-type d’« Object » et de « int ».

Comme l’explique Goetz, « l'un des premiers compromis avec les génériques en Java est que ces variables ne peuvent être instanciées qu’avec les types de référence, et non pas les types primitifs […] Nous voulons permettre aux classes génériques existantes d’être améliorées, sans avoir à les jeter et les remplacer par de nouvelles. Et en même temps ne pas forcer les programmes existants à être recompilés ou modifiés simplement pour continuer à travailler ».

Pour cela, plusieurs techniques potentielles sont en train d’être étudiées. L’une des pistes les plus prometteuses, appelée « generic specialization », consiste à continuer à représenter les types du genre List<Integer> et List<String> par List.class dans le runtime, tandis que les nouvelles déclarations du genre List<int> seront représentées par un autre type.

L’équipe du projet Valhalla est en train de préparer un prototype pour tester cette technique. Cependant, il est encore tôt pour savoir si elle permet de résoudre efficacement tous les problèmes actuels du typage générique de Java.

Source : Open JDK

[thelvin]

Hmmm. Bon ça a l'air de marcher. Ça va encore démultiplier les classes à charger en mémoire mais ça on n'y aurait pas coupé à un moment ou à un autre.

Ça va tout de même commencer à devenir compliqué, la lecture des JavaDoc des classes standard Java : "alors les méthodes remove(Object) et remove(int) elles existent que sur les instances où le E de List<E> est un type référence. Pour les types primitifs ça existe pas, utilisez removeItem(E) et removeIndex(int)"
Si ce truc passe je tire mon chapeau à ceux qui arrivent encore à décrocher des certifs Java.

[adiGuba]

Hmmm. Bon ça a l'air de marcher. Ça va encore démultiplier les classes à charger en mémoire mais ça on n'y aurait pas coupé à un moment ou à un autre.

C'est atténué par le fait que cela ne concernera que les primitifs/valeurs.
Les Generics avec des références fonctionneront toujours de la même manière.

Ça va tout de même commencer à devenir compliqué, la lecture des JavaDoc des classes standard Java : "alors les méthodes remove(Object) et remove(int) elles existent que sur les instances où le E de List<E> est un type référence. Pour les types primitifs ça existe pas, utilisez removeItem(E) et removeIndex(int)"

Dans l'idée removeItem(E) et removeIndex(int) seront disponible pour tous les types, et les remove(Object)/remove(int) accessible uniquement pour les références pour la rétrocompatibilité.

Depuis Java 8 la javadoc inclut des onglets pour regrouper les méthodes selon plusieurs critères (instance, static, abstraite, concrète, default...).
On aura peut-être de nouveaux onglets pour gérer cela...

Mieux : c'est absent de ce document, mais dans la version précédente ils parlaient carrément de pouvoir faire une implémentation spécifique pour certains types.
Il serait ainsi possible par exemple d'avoir une implémentation d'ArrayList<boolean> basé sur un BitSet au lieu d'un boolean[]

Je comprend pas bien ce genre d'évolution qui n'apporte pas grand chose.

C'est un prérequis à l'intégration des types valeurs.
Il serait absurde d’insérer des types valeurs dans le langage si on ne peut pas les utiliser avec les Generics.

Il ferait mieux de faire en sorte de faire évoluer java pour avoir des performance équivalente a du C++.

Troll ? Ou alors tu es resté bloqué sur la fin des années 90 ?
Un peu de sérieux voyons...

La nouvelle fonctionnalité values prévu je sais pas dans quelle version était très intérréssante.

Ben c'est le même projet : tout ceci est lié.
Sans specialization l'utilisation des types valeurs risque d'être problématique...

Sinon une fonctionnalité a embarquer dans JDK serait de pouvoir produire un executable qui ne néssécité pas d'avoir un JRE d'installer sur le PC.

Cela existe déjà (mais pas dans le JDK en effet).
Par contre je n'y vois pas grand intérêt...

Je pense java souffre d'un seul problème ne pas être totalement géré comme python ou C++ pas communauté indépendante.

Je ne comprend pas trop.
Même si c'est chapeauté par Oracle l'évolution de Java est entre les mains de plusieurs entreprises/organisations...

C'est vraiment n'importe quoi cette techno

Soit tu argumentes, soit c'est du troll pure et le mieux serait d'aller voir ailleurs.
Ici on préfère les discussions argumentés aux petites phrases toutes faites qui ne veulent rien dire...

Ça sert à quoi d'avoir des types primitifs ?

Les types primitifs sont des types de base sans notion d'identité. Ils ne représente qu'un espace mémoire réservé à la valeur qu'ils représente.
Les types valeurs sont des types primitifs un peu plus évolué, dans le sens où ils peuvent être composé de plusieurs éléments (un peu comme une structure en C).

Leurs utilités en Java est restreinte, car en les utilisant on "perd" plein de fonctionnalité (pas d'héritage).

Toutefois cela a deux gros intérêts :

• Une occupation mémoire fixe, qui permet des allocations en bloc pour les tableaux.
  Un tableau de 10 int occupera toujours la même taille en mémoire quelque soit les valeurs stockées, tandis qu'un tableau de 10 Object occupera plus ou moins de mémoire selon les objets qu'on y met.
• Elle ne comporte que des données, et aucune informations d'identité propre à l'héritage et la POO.
  Cela permet d'être "partagé" plus facilement avec du code natif, ou des instructions bas-niveau, sans avoir à faire des conversions dans tous les sens.

C'est important lorsqu'on fait des traitements 3D ou d'autres choses qui peuvent être manipulé directement par le GPU : on génère les données en Java et on les passe tel-quel pour un traitements optimisés (voir même parallélisés).

En tous cas c'est une très bonne chose qu'ils se penchent enfin sur l'amélioration des génériques; c'est vraiment la feature la plus bancale de Java... Le design actuel partait d'un bon sentiment (garder la compatibilité avec le code déjà compilé existant), mais ça introduit tellement de limitations qu'à mon avis les inconvénients surpassent largement les bénéfices.

Ils ne vont pas tout changer : les Generics fonctionneront quasiment de la même manière pour les objets.
Ils vont juste introduire une système de template (un peu à la C#), mais uniquement pour les primitives/valeurs.

Sinon perso je ne trouve pas que l'implémentation des Generics soit aussi mauvaise que tout le monde le laisse entendre.
Au contraire je trouve que ses inconvénients sont largement plus décriés qu'ils ne le devraient, et qu'ils y a d'autres avantages qui sont mis sous silence :

• La compatibilité avec le code déjà compilé comme tu le dis,
• Mais également l’inter-compatibilité entre du code n'utilisant pas les Generics, et du code les utilisant, au sein d'un même programme sans avoir à faire des conversions.
• Une covariance/contravariance plus complète, et pas limité à la déclaration du type, et cela dès le début.
• Une compatibilité avec tous les langages tournant sur une JVM, même si ceux-ci n'ont pas forcément de notion de Generics.

a++

[tomlev]

Ils vont juste introduire une système de template (un peu à la C#), mais uniquement pour les primitives/valeurs.

En C# c'est pas vraiment un système de template (dans le sens des templates C++). Le compilateur produit un seul type générique ouvert, et c'est au runtime que les types fermés sont créés (éventuellement dynamiquement par réflexion). Alors qu'en C++, toutes les instanciations d'un template sont générées directement à la compilation ; ça a certains avantages (performance, plus de souplesse puisqu'on peut faire n'importe quelle opération dans un template du moment que le type utilisé lors de l’instanciation le supporte), mais ça a l'inconvénient d'être complètement statique...

[*] Une covariance/contravariance plus complète, et pas limité à la déclaration du type, et cela dès le début.

Oui mais la variance des génériques en Java n'est pas type-safe... Petit exemple de quelque chose qui va compiler sans problème mais échouer à l'exécution :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
import java.util.List;
import java.util.ArrayList;
 
public class GenericTypeErasure {
  public static void main(String[] args) {
    List<Foo> fooList = new ArrayList<Foo>();
    List<?> list = fooList;
    List<Bar> barList = (List<Bar>)list;
    barList.add(new Bar()); // no error
    Foo foo = fooList.get(0); // java.lang.ClassCastException: HelloWorld$Bar cannot be cast to HelloWorld$Foo
  }
 
  static class Foo {
  }
 
  static class Bar {
  }
}

En C#, ce serait impossible. Les classes génériques ne sont pas variantes ; seules les interfaces (et les delegates) peuvent l'être, mais il y a des contraintes. Par exemple, l'interface IList<T> n'est pas covariante, parce que T apparait à la fois en sortie et en entrée (un IList<String> ne peut donc pas être affecté à un IList<Object>). Par contre, IEnumerable<T> est covariante, car T n'apparait qu'en sortie (un IEnumerable<String> peut être affecté à un IEnumerable<Object>)

Après, je reconnais volontiers que l'approche de Java a certains avantages... Il m'arrive occasionnellement de regretter que les wildcards n'existent pas en C#, même s'ils présentent certains risques (comme l'exemple ci-dessus)