Discussion :

[adiGuba]

La suite de la discussion est nettement mieux : http://mail.openjdk.java.net/piperma...ry/thread.html

Et cela soulève (à mon sens) le principal problème de tout cela : les types values vont complexifier un peu plus le langage, alors que c'est quelque chose qui peut s'avérer "inutile" pour bon nombre de développeurs Java...


a++

[Gugelhupf]

Il n'est pas possible d'utiliser T.class, new T() et new T[] directement dans le code.

Et aussi le fait de :

• ne pas pouvoir surcharger les méthodes avec des paramètres génériques, ex: toto(List<Integer> a) toto(List<Double> a)
• ne pas pouvoir instancier des List generic de tableau, ex: new List<Integer>[10];, et donc passer par des casts explicites supplémentaires.
• forcer l'ajout du paramètre Class<T> dans les méthodes, avoir recours à des méthodes tels que newInstance().

Je sais que c'est bête mais le compilateur ne pourrait pas bêtement remplacer int par Integer pour les types génériques, ajouter les casts nécessaires pour les tableaux de liste générique etc ? Quelque chose me dit qu'on ne fait pas cela à cause des programmes qui ont beaucoup recours à l'introspection.

[tomlev]

Je sais que c'est bête mais le compilateur ne pourrait pas bêtement remplacer int par Integer pour les types génériques, ajouter les casts nécessaires pour les tableaux de liste générique etc ?

Il pourrait, mais ça ne règlerait pas le problème pour les types valeur qui vont être ajoutés dans le langage...

De plus, le boxing n'est pas gratuit ; une solution qui permettrait d'éviter le boxing serait plus performante.

[adiGuba]

Et aussi le fait de :

• ne pas pouvoir surcharger les méthodes avec des paramètres génériques, ex: toto(List<Integer> a) toto(List<Double> a)
• ne pas pouvoir instancier des List generic de tableau, ex: new List<Integer>[10];, et donc passer par des casts explicites supplémentaires.
• forcer l'ajout du paramètre Class<T> dans les méthodes, avoir recours à des méthodes tels que newInstance().

Je ne vois rien d'absolument primordiale là dedans. C'est des features qui peuvent être sympa le jour où on en a besoin, mais les solutions alternatives existent et ne sont pas forcément mauvaise.

• La surcharge de nom c'est bof et cela amène des ambiguïtés voir des problèmes (cf les méthodes remove() de List )
  Il est préférable d'utiliser des noms différents pour chaque méthode. ex : totoByInts(List<Integer> a) totoByDoubles(List<Double> a)Voir lorsque c'est possible d'utiliser un type parent. ex : toto(List<? extends Number>).
  
  Le plus gros problème c'est que cela empêche d'implémenter deux fois la même interface (je ne sais plus si j'en ai parlé sur cette discussion), mais
  
• List<Integer>[] array = new List[10];Ok cela génère un warning "unchecked", mais c'est logique puisque les tableaux ne sont pas typesafe (et les Generics garantissent du code typesafe à la compilation).
  Si on veut du code sécurisé il faut utiliser du code qui l'est : List<List<Integer>> lists = new ArrayList<List<Integer>>().
  
• Si on a besoin seulement d'instancier un objet, on peut passer par une fabrique (c'est d'ailleurs ce qu'on retrouve généralement dans les APIs pour ce besoin).
  En plus en Java 8 avec les références de constructeur cela se crée en deux-deux : MonType::new

Non franchement je ne vois pas la "super-feature" manquante qui remettrait en cause le choix d'implémentation des Generics...

Je sais que c'est bête mais le compilateur ne pourrait pas bêtement remplacer int par Integer pour les types génériques, ajouter les casts nécessaires pour les tableaux de liste générique etc ? Quelque chose me dit qu'on ne fait pas cela à cause des programmes qui ont beaucoup recours à l'introspection.

Ben c'est déjà possible depuis Java 5.0 : il suffit d'utiliser un List<Integer> par exemple.
(ou alors je n'ai pas compris ce que tu voulais dire)



Ces nouvelles fonctionnalités (type valeur et specialisation des Generics) ne seront pas forcément utiles aux développeurs Java "classique" qui continueront à utiliser des objets classiques.
Tout ceci devient par contre primordiale lorsqu'on doit communiquer directement avec du code natif ou du materiel.
En effet il s'agit de type de données plus simple (sans notion d'identité), mais qui pourront être partagé plus facilement en dehors de Java, sans avoir à faire des conversions dans tous les sens.


a++

[Gugelhupf]

Oui il n'y a rien de primordiale, on peut toujours se passer de certaines choses (les lambdas par exemple), mais c'est sympa aussi de gérer certains cas. Je n'ai pas forcément envie de polluer mes signatures de méthode avec Class<T> par exemple.

Je ne suis pas fan de nommer mes méthodes avec des types (cf: totoInt() ou totoDouble()), et il n'y a pas d'utilité à utiliser toto(List<? extends Number>) si on a deux méthodes toto() contenant des instructions différentes. Nous sommes tout de même dans un langage orienté objet, la surcharge existe, et faire exception pour les génériques c'est étrange.

Je ne sais pas si List<Integer>[] array = new ArrayList<Integer>[10]; ou List<Integer>[] array = new ArrayList<>[10]; aurait généré un warning mais je trouve cet écriture plus logique. Je sais bien qu'il est toujours possible d'utiliser des listes de liste au lieu de tableau, mais on ne peut tout de même pas supprimer l'utilisation des tableaux, théoriquement l'utilisation des tableaux est plus rapide que des listes, donc autant en profiter lorsque le nombre d'élément d'un container est fixe.

Je peux écrire List<Integer> mais pas List<int>, du coup je me demandais si pour ces cas "on" (le compilateur) pouvait faire en sorte de remplacer int par Integer, mais je pense que ce n'est pas possible car cela impacterait les programmes qui utilisent la reflection.

[adiGuba]

Oui il n'y a rien de primordiale, on peut toujours se passer de certaines choses (les lambdas par exemple), mais c'est sympa aussi de gérer certains cas. Je n'ai pas forcément envie de polluer mes signatures de méthode avec Class<T> par exemple.

La différence c'est que les lambdas s'intègrent bien dans le langage, et sont même compatible avec des APIs bien antérieure.

Ce que tu demandes aurait amené nettement plus de problèmes : disparition de la notion de covariance/contravariance, incompatibilité avec le code existant, migration impossible et duplication des APIs (standard et tierces).
Est-ce vraiment si important pour tout remettre en cause ?

Je ne suis pas fan de nommer mes méthodes avec des types (cf: totoInt() ou totoDouble()), et il n'y a pas d'utilité à utiliser toto(List<? extends Number>) si on a deux méthodes toto() contenant des instructions différentes. Nous sommes tout de même dans un langage orienté objet, la surcharge existe, et faire exception pour les génériques c'est étrange.

Pourquoi deux méthodes avec le même nom si les instructions sont différentes ?

Plus sérieusement perso c'est la notion même de surcharge que je trouve plus problématique.
C'est un mal un peu nécessaire pour les primitives (qui ne peuvent pas avoir un type commun), mais cela peut poser pas mal d’ambiguïté (surtout si c'est couplé avec de l'héritage).
Mais bon c'est un peu un autre débat.

Je ne sais pas si List<Integer>[] array = new ArrayList<Integer>[10]; ou List<Integer>[] array = new ArrayList<>[10]; aurait généré un warning mais je trouve cet écriture plus logique. Je sais bien qu'il est toujours possible d'utiliser des listes de liste au lieu de tableau, mais on ne peut tout de même pas supprimer l'utilisation des tableaux, théoriquement l'utilisation des tableaux est plus rapide que des listes, donc autant en profiter lorsque le nombre d'élément d'un container est fixe.

Je ne comprend pas : l'utilisation des tableaux n'est pas supprimé !
Le warning signale juste un problème vis à vis du fait que les tableaux ne sont pas typesafe, ce qui va donc à l'encontre même de l'objectif des Generics. C'est tout...

Je peux écrire List<Integer> mais pas List<int>, du coup je me demandais si pour ces cas "on" (le compilateur) pouvait faire en sorte de remplacer int par Integer, mais je pense que ce n'est pas possible car cela impacterait les programmes qui utilisent la reflection.

Je ne comprend pas pourquoi tu voudrais écrire List<int> si c'est pour que cela fonctionne comme un List<Integer>.
Autant utiliser ce dernier directement.

Car justement le vrai intérêt de ces évolutions c'est justement que List<int> utilisera vraiment des int en interne.


a++

[Logan Mauzaize]

Ayant la flemme de lire, les types primitifs ne sont pas compatibles avec la valeur null. Je suppose que rien n'a changé dans la proposition ?
La problématique des cas comme Map est-elle traité ? Bien que dans Java 8, ils aient ajouté les notions "IfAbsent"/"IfPresent" et "DefaultValue" dans les collections ...

Par contre, j'ai une proposition toute conne pour les types primitifs. Pourquoi ne pas supprimer les "Wrappers" et utiliser des "paliatifs" simples pour le stockage en mémoire : tant que le type est sûr (sur la pile notamment, on ne stocke que la valeur binaire) et là où le type n'est pas sûr on stocke le valeur binaire plus un code sur 8-bits indiquant le type.
Exemple de codage du type :

Code text :

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

1
2
7    6        5      4   3  2  1  0
null flottant signé  taille (0=8bits, 10=16bits, 11=32bits, 100=64bits, etc.)

Les "wrappers" ne seraient que des interfaces dont les appels de méthodes seraient convertis lors de la compilation.
Exemple:

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
19
// Vue développeur
class int {
  public String toString() {
    // ...
  }
}
public static void main(String[] args) {
  System.out.println(42.toString());
}
 
// Vue JVM
abstract final class int { // Non instanciable : class utilitaire
  public static String toString(int i) {
    // ...
  }
}
public static void main(String[] args) {
  System.out.println(int.toString(42));
}

Concernant le type-system de Java, je le trouve pas si compliqué. Mais je préfère largement celui de Ceylon conçu par .... le même fameux Gavin King qui proposait une autre façon d'aborder le problème. En ayant déporté la variance au niveau de la déclaration du type ("declaration-site variance" vs "use-site variance", Wikipedia, Gavin King), on sépare dans les interfaces la partie "production" (retour) et "consommation" (paramètre). Les APIs et l'utilisation sont beaucoup plus simple et lisible.

Comme adiGuba, les génériques ne sont vraiment pas le truc le plus chiant comparé aux CheckedException et l'absence de type non signé, surtout "byte". D'autant que dans le premier cas, il n'y aurait rien d'alarmant à les rendre désactivable puisque le bytecode n'y ait pas sensible.

[adiGuba]

Ayant la flemme de lire, les types primitifs ne sont pas compatibles avec la valeur null. Je suppose que rien n'a changé dans la proposition ?
La problématique des cas comme Map est-elle traité ? Bien que dans Java 8, ils aient ajouté les notions "IfAbsent"/"IfPresent" et "DefaultValue" dans les collections ...

Les types primitifs resteront tel quel (et donc n'accepterons pas null).
Quand aux cas comme Map, la specialization des Generics permettra de définir du code et des méthodes spécifiques pour des types.
Ainsi get(K) sera réservé aux objets, et on sera obligé de passer par getOrDefault(K,V) pour les types primitifs/values...

Par contre, j'ai une proposition toute conne pour les types primitifs. Pourquoi ne pas supprimer les "Wrappers" et utiliser des "paliatifs" simples pour le stockage en mémoire : tant que le type est sûr (sur la pile notamment, on ne stocke que la valeur binaire) et là où le type n'est pas sûr on stocke le valeur binaire plus un code sur 8-bits indiquant le type.

Le premier point est déjà fait par la JVM, qui peut optimiser pas mal de chose vira l'inlining et l'escape analysis...

Après changer la manière de stocker les primitifs n'apportera pas grand chose : ce ne sera pas aussi performants que de vrai primitif, et cela restera incompatible avec le code natif.
En Java il n'y a pas vraiment de gros soucis à passer par les types Wrapper.
Le problème c'est qu'on ne peut pas les passer tel quel vers le natif (logiciel ou matériel).


Et justement l'objectif des types valeurs est de définir des types values est de permettre de définir des structures de données identiques à ceux qu'on retrouve en natif, pour faciliter le partage des données.

Concernant le type-system de Java, je le trouve pas si compliqué. Mais je préfère largement celui de Ceylon conçu par .... le même fameux Gavin King qui proposait une autre façon d'aborder le problème. En ayant déporté la variance au niveau de la déclaration du type ("declaration-site variance" vs "use-site variance", Wikipedia, Gavin King), on sépare dans les interfaces la partie "production" (retour) et "consommation" (paramètre). Les APIs et l'utilisation sont beaucoup plus simple et lisible.

Oui une "declaration-site variance" est plus simple et lisible, même si elle a ses propres défauts (déclaration sur le type uniquement, découpage en plusieurs sous-interfaces, moins de cohérence de l'ensemble...).
En même temps il faut dire que les wildcards de Java sont vite très difficile à lire !

Au passage voir l'URL de la JEP que j'ai évoqué plus haut dans cette discussion (si je ne me trompe pas), et qui consiste à apporter la "declaration-site variance" dans Java : http://openjdk.java.net/jeps/8043488

Comme adiGuba, les génériques ne sont vraiment pas le truc le plus chiant comparé aux CheckedException et l'absence de type non signé, surtout "byte". D'autant que dans le premier cas, il n'y aurait rien d'alarmant à les rendre désactivable puisque le bytecode n'y ait pas sensible.

Les types values devraient permettre de créer des types non-signé (entre autres).


a++

[Logan Mauzaize]

...

Merci pour ces explications, professeur !

Les types primitifs resteront tel quel (et donc n'accepterons pas null).
Quand aux cas comme Map, la specialization des Generics permettra de définir du code et des méthodes spécifiques pour des types.
Ainsi get(K) sera réservé aux objets, et on sera obligé de passer par getOrDefault(K,V) pour les types primitifs/values...

C'est quoi la syntaxe retenue pour indiquer qu'une méthode est spécifique au référence ? Est-ce que l'on peut également faire l'inverse, avoir des méthodes spécifiques pour les valeurs ?

Concrètement au niveau des classes ? On aura la construction dynamique d'une nouvelle classe pour les valeurs ? (Ex: List<int>.class != List<Object>.class).
Si oui, il y aura une classe par type valeur ou seulement une pour les références et une autre pour les valeurs ?
Et qui des types génériques qui accepteront plusieurs type paramétré "any" (ex: Map<any K, any V>)

Le premier point est déjà fait par la JVM, qui peut optimiser pas mal de chose vira l'inlining et l'escape analysis...

Ce que je propose c'est de supprimer le boxing. C'est en tout cas la problématique mise en avant par le papier :

Après changer la manière de stocker les primitifs n'apportera pas grand chose : ce ne sera pas aussi performants que de vrai primitif, et cela restera incompatible avec le code natif.
En Java il n'y a pas vraiment de gros soucis à passer par les types Wrapper.
Le problème c'est qu'on ne peut pas les passer tel quel vers le natif (logiciel ou matériel).
Et justement l'objectif des types valeurs est de définir des types values est de permettre de définir des structures de données identiques à ceux qu'on retrouve en natif, pour faciliter le partage des données.

Ce que je propose c'est justement de garder des primitifs et juste d'ajouter la surcouche nécessaire au type safe là ou c'est nécessaire (bien que je ne suis pas sûr que ce le soit). Beaucoup de langages passent par le tout objet, il serait intéressant de voir comment ils gèrent tout ca.
Pour moi, les types primitifs doivent être vu par le codeur comme un type référence et exploiter en interne de manière native avec des appels statiques dans le bytecode et inliner au JIT.

Oui une "declaration-site variance" est plus simple et lisible, même si elle a ses propres défauts (déclaration sur le type uniquement, découpage en plusieurs sous-interfaces, moins de cohérence de l'ensemble...).
En même temps il faut dire que les wildcards de Java sont vite très difficile à lire !

Les wildcards sont difficiles à lire et à manipuler. On se demande toujours à quel cas correspond la covariance et la contravariance et avec quel mot clé on l'exprime (extends ou super). C'est pourquoi je préfère les mots clé de Ceylon : in / out. Et le découpage des interfaces d'un côté le consommateur et de l'autre le producteur.
On se retrouve parfois avec des incompatibilités de type alors que ce ne devrait pas être le cas.

Les types values devraient permettre de créer des types non-signé (entre autres).

Le problème c'est qu'à moins de casser la rétrocompatibilité, il est déjà trop tard. Toutes les méthodes qui manipulent des byte sont signés. En espérant qu'ils ajoutent tout de même un unsigned byte en natif avec éventuellement un moyen de conversion "transparent" pour passer de l'un à l'autre. Ainsi on pourrait réutiliser les APIs existantes.
Bien que je vois pas comment optimiser le cas des tableaux ...

[adiGuba]

C'est quoi la syntaxe retenue pour indiquer qu'une méthode est spécifique au référence ? Est-ce que l'on peut également faire l'inverse, avoir des méthodes spécifiques pour les valeurs ?

La syntaxe n'est pas du tout définitive. Pour le moment elle n'est donné que pour pouvoir "tester", mais il y a de forte chance que cela change.
Dans la dernière proposition il faut utiliser des layer pour définir des bloc de codes disponible pour l'un ou l'autre :

Code :

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

1
2
3
4
5
6
7
8
9
10
interface Exemple<any T> {
 
    public T methodeCommune();
 
    layer<ref T> {
 
        public T methodPourLesObjects();
 
    }
}

On peut bien sûr définir des méthodes/attributs uniquement pour les valeurs avec layer<value T> (ce qui regroupe primitifs et type values).
Il devrait même être possible de définir cela pour un type précis (layer<T=int>) voir même selon selon des critères d'héritage (layer<T extends Comparable<T>>).

Concrètement au niveau des classes ? On aura la construction dynamique d'une nouvelle classe pour les valeurs ? (Ex: List<int>.class != List<Object>.class).
Si oui, il y aura une classe par type valeur ou seulement une pour les références et une autre pour les valeurs ?
Et qui des types génériques qui accepteront plusieurs type paramétré "any" (ex: Map<any K, any V>)

Oui : on conservera une classe commune pour les références (comme actuellement), mais il y aura une classe pour chaque configuration utilisant une primitif/valeur.
Toutefois comme en C# cela devrait être fait dynamiquement à l'exécution (ie : lorsque tu compiles ta classe tu as un fichier .class, et la JVM génèrera automatiquement les différentes classes à l'utilisation).
Et on pourra bien sûr avoir plusieurs types génériques "anyifié" (ex: Map<any K, any V>)

Ce que je propose c'est de supprimer le boxing. C'est en tout cas la problématique mise en avant par le papier :

Oui mais grosso-modo ta solution consiste à donner une identité aux primitives, en y ajoutant un header le décrivant.

Or si on veut partager les données avec du code natif, on ne peut pas utiliser cela car on doit utiliser exactement la même structure mémoire...

Ce que je propose c'est justement de garder des primitifs et juste d'ajouter la surcouche nécessaire au type safe là ou c'est nécessaire (bien que je ne suis pas sûr que ce le soit). Beaucoup de langages passent par le tout objet, il serait intéressant de voir comment ils gèrent tout ca.
Pour moi, les types primitifs doivent être vu par le codeur comme un type référence et exploiter en interne de manière native avec des appels statiques dans le bytecode et inliner au JIT.

La JVM fait déjà pas mal de chose comme cela.
Le problème c'est pas vraiment les performances de la JVM en elle même, mais plus de la manière dont on communique avec "l'extérieur".
Passes une zone mémoire avec un tel header vers du code natif, et il ne pourra pas le lire "nativement".

Or l'objectif des types values c'est surtout ca : pourvoir représenter des données en mémoire de la même manière qu'en natif, afin de pouvoir communiquer plus facilement avec du natif (que ce soit logiciel ou hardware).

Les wildcards sont difficiles à lire et à manipuler. On se demande toujours à quel cas correspond la covariance et la contravariance et avec quel mot clé on l'exprime (extends ou super). C'est pourquoi je préfère les mots clé de Ceylon : in / out. Et le découpage des interfaces d'un côté le consommateur et de l'autre le producteur.
On se retrouve parfois avec des incompatibilités de type alors que ce ne devrait pas être le cas.

Oui, c'est bien ce que je dis : les wildcards sont plus complexes, mais permettent aussi plus de chose.

Le problème c'est qu'à moins de casser la rétrocompatibilité, il est déjà trop tard. Toutes les méthodes qui manipulent des byte sont signés. En espérant qu'ils ajoutent tout de même un unsigned byte en natif avec éventuellement un moyen de conversion "transparent" pour passer de l'un à l'autre. Ainsi on pourrait réutiliser les APIs existantes.
Bien que je vois pas comment optimiser le cas des tableaux ...

Non justement les types values devraient permettre cela. On pourra définir une infinité de type...
Après tout en mémoire il n'y a aucune différence entre un byte et un unsigned byte : il s'agit juste d'un octet.
La seule différence vient de l'implémentation des calculs et des opérations que l'on effectue dessus (d'ailleurs Java 8 a rajouté des méthodes dans les classe Integer/Long afin de traiter les int/long en tant qu'unsigned.)

Il serait donc possible de définir un type value contenant un byte, que l'on manipulerait comme un unsigned.



a++

[Logan Mauzaize]

Oui mais grosso-modo ta solution consiste à donner une identité aux primitives, en y ajoutant un header le décrivant.

En fait le header doit être optionel, et si nécessaire correctement placé. Je suis pas franchement calé pour ce qui concerne la sécurité des types dans la JVM mais je sais que les références sont toutes typées pour s'assurer que les opérations s'appliquent bien. C'est pourquoi je proposais ce header pour typé les types primitifs.
Cependant je suis à peu près sûr que ce header n'est pas nécessaire tant qu'on ne manipule pas de "Number". En fait le header vient assurer la hiérarchie type ce qui n'est pas possible pour les types valeurs (qui incluent les primitifs).

Si ce header était nécessaire, il faudrait le positionner correctement, c'est-à-dire au début de l'objet qui la contient dans une sorte de cartographie des types primitifs (un peu à l'image d'une table des partitions sur un disque).

Or si on veut partager les données avec du code natif, on ne peut pas utiliser cela car on doit utiliser exactement la même structure mémoire...

1. Dans la mesure où il s'agit de type valeur, il suffit de provoquer un réalignement des données lorsque la donnée est mise sur la pile avant appel.
2. Avec le principe de "cartographie", il suffit de passer l'adresse après la cartographie pour obtenir la bonne adresse mémoire pour le natif.
3. Dans la mesure où l'on ne possède pas de telles structures mémoire, il faut bien aujourd'hui faire un micmac. D'autant plus que si la structure native est mal alignée avec celle de Java, il y a un risque de violation du type.
4. Dans la mesure où un jour on possède de telles structures, la cartographie ne concerne que les références. Et il faudra bien spécifier comment passer les références vers le natif (si on l'autorise ?).

Non justement les types values devraient permettre cela. On pourra définir une infinité de type...
Après tout en mémoire il n'y a aucune différence entre un byte et un unsigned byte : il s'agit juste d'un octet.
La seule différence vient de l'implémentation des calculs et des opérations que l'on effectue dessus (d'ailleurs Java 8 a rajouté des méthodes dans les classe Integer/Long afin de traiter les int/long en tant qu'unsigned.)
Il serait donc possible de définir un type value contenant un byte, que l'on manipulerait comme un unsigned.

Raaaaaaaah pourquoi il n'ont pas ajouté compareUnsigned à Byte ???
Si on peut "convertir nativement" (copie bit-à-bit) un byte en unsigned byte ce sera vraiment pas mal ! En supposant que les "overflow" soient gérés de la même manière :

Code Java :

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

1
2
byte sb = -128;
unsigned_byte ub = sb; // 128