Discussion :

[thelvin]

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[]

C'est pas absent du tout, ils en parlent.
Et ma foi la syntaxe temporaire layer<boolean> { ... } permet ce genre de choses telle que, en surchargeant des méthodes qui sont hors de tout layer.

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 :

"Sans problème" avec un warning visible depuis la lune .
Ton IDE peut être configuré pour refuser de compiler ça si tu préfères, et le @SuppressWarnings("unchecked") est là pour les cas pathologiques où tu voudrais, en fait, pouvoir faire ça en disant au compilateur que tu sais ce que tu fais et qu'il n'a pas à s'en mêler.

[adiGuba]

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...

Le fonctionnement des Templates du C++ et des Generics du C# reste proche dans les grandes lignes, même s'il est vrai que les types finaux ne sont pas créé au même moment, mais c'est aussi surtout parce que l'édition des liens n'est pas fait au même moment...

Oui mais la variance des génériques en Java n'est pas type-safe...

Non : la variance et plus globalement les Generics sont complètement typesafe, à partir du moment où on l'utilise de bout en bout et que le code ne génère pas de warning.

Petit exemple de quelque chose qui va compiler sans problème mais échouer à l'exécution :

Comme l'indique thelvin ton code génère un warning, donc le problème est bien signalé.

Mais surtout le problème ne vient pas de la variance, mais du cast. D'ailleurs on pourrait remplacer List<?> par Object pour un résultat identique.
Les casts ne sont pas typesafe, et un mauvais cast peut provoquer une ClassCastException... et c'est ce qui arrive.


Perso je vois juste 3 principaux inconvénients à l'implémentation des Generics de Java :

• Il n'est pas possible d'utiliser des types primitifs (pour le moment donc).
• Il n'est pas possible d'utiliser T.class, new T() et new T[] directement dans le code.
  Même si on peut faire la même chose en utilisant un paramètre de type Class<T> à la construction de l'instance, le tout couplé avec l'API de reflection.
• Les casts ne sont qu'à demi-vérifié (les paramètres Generics sont ignoré), et on ne peut pas utiliser instanceof.
  Mais en même temps tout l'objectif des Generics consiste à éviter les casts/instanceof...

Perso en Java je suis plus souvent gêné par la notion de "checked-exception", que par l'implémentation des Generics.

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.

Et pourtant le code suivant est l'équivalent C#, il compile (sans erreur ni warning) et génère une belle exception à l'exécution :

Code C# :

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

1
2
3
4
5
		IList<Foo> fooList = new List<Foo>();
    	IEnumerable<object> list = fooList;
    	IList<Bar> barList = (IList<Bar>)list; // InvalidCastException
    	barList.Add(new Bar());
    	Foo foo = fooList[0];

le problème ne vient pas de la variance, mais bien du cast
La seule différence vient du fait que l'exception survient plus tôt, et c'est là le gros avantage de la reification : les problèmes sont détecté au plus tôt et l'erreur remonte immédiatement !

Mais dans les deux cas il s'agit d'une utilisation incorrecte et d'un cast barbare incorrect...

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>)

Oui : c'est un peu moins "puissant" et peut être un peu ambigu (les règles changent d'un type à l'autre), mais cela a le gros avantage de proposer une syntaxe plus lisible (car les wildcards peuvent rapidement devenir illisible).
D'ailleurs il y avait une JEP s'en inspirant fortement : http://openjdk.java.net/jeps/8043488

C'est pas absent du tout, ils en parlent.
Et ma foi la syntaxe temporaire layer<boolean> { ... } permet ce genre de choses telle que, en surchargeant des méthodes qui sont hors de tout layer.

Oui en effet on peut faire la même chose avec les layers.
En fait ce qui m'a trompé c'est qu'ils présentaient deux syntaxes différentes dans la première proposition...



a++

[super_navide]

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

Il ferait mieux de faire en sorte de faire évoluer java pour avoir des performance équivalente a du C++.
La nouvelle fonctionnalité values prévu je sais pas dans quelle version était très intérréssante.
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.

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

Mais bon malgré. tous ses défaut je pense que c le meilleur langage car on peut tous faire avec java.

Mais c# arrive pas loin , avec le nouveau framework que microsoft fait qui permet d'écrire une application pour la plupard des plateformes est intéressant.
Mais c# souffre du même problème que java il est la propriété de microsoft.

[redcurve]

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

Il ferait mieux de faire en sorte de faire évoluer java pour avoir des performance équivalente a du C++.
La nouvelle fonctionnalité values prévu je sais pas dans quelle version était très intérréssante.
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.

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

Mais bon malgré. tous ses défaut je pense que c le meilleur langage car on peut tous faire avec java.

Mais c# arrive pas loin , avec le nouveau framework que microsoft fait qui permet d'écrire une application pour la plupard des plateformes est intéressant.
Mais c# souffre du même problème que java il est la propriété de microsoft.

C# n'est pas la propriété de MS c'est une spec, pareil pour la CLR et la CLI.

Le .net Framework n'est qu'une implémentation de la CLR/CLI sous Windows.

Toutes les specs sont dispo librement sur le site de l'ECMA

[redcurve]

C'est vraiment n'importe quoi cette techno

[ternel]

Justement, pouvoir avoir des list<int> qui ne passent pas par une conversion vers Integer pourra fortement augmenter les performances de tout programme de calcul.

Quant à "je pense que c'est le meilleur langage parce qu'on peut tout faire", c'est aussi vrai pour tout un tas d'autres langages, comme le C++, le C#, le python, etc.
Le bon outil est celui adapté à la tache.

Personne ne dira "le marteau est le meilleur outil", pourtant, on peut tout faire avec... planter des vis (c'est pas idéal, mais ca marche), cirer des chaussures, démarrer un tracteur, et même coudre un bouton.

[gstratege]

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

[tomlev]

Mais c# souffre du même problème que java il est la propriété de microsoft.

C'est plus tout à fait vrai :
- d'une part, le langage est standardisé par l'ECMA (du moins jusqu'à la version 2 ; je ne sais pas s'ils ont l'intention de faire standardiser les versions suivantes)
- d'autre part, le compilateur est maintenant open-source et cross-platform, et la communauté est fortement impliquée dans sa conception

Certes, c'est toujours Microsoft qui pilote l'évolution du langage, mais je ne vois pas en quoi c'est pire que Java qui est maintenant piloté par Oracle...

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

Pour des questions de performance, principalement. Les types primitifs correspondent directement à des types de données supportés par le processeur (int, double, etc), qui peuvent donc être traités très efficacement.


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.

[oallouch]

Brian Goetz et son équipe avancent vraiment bien côté langage.
Les lambdas de Java 8 sont une merveille (regardez le source de la classe utilitaire Collectors).
Ils ont pris le temps mais c'est du bon !
Avec ces maj dans Java 9, ils vont résoudre le truc le plus chiant avec les lambdas pour les Collections:
ils vont pouvoir ajouter une méthode stream() à l'interface Iterator...le bonheur !

Maintenant, il faudrait vraiment qu'ils se penchent (je crois qu'ils le font) sur la pauvreté du Hot Swap standard et la nécessité pour tous d'avoir en standard (et gratuit) un truc équivalent à JRebel. Il existe déjà des produits open source (moyennement supportés) comme DCEVM.

Mais, je peux vous dire que quand vous passez de Javascript (quand vous codez votre UI) à Java (pour le serveur), vous respirez !

Olivier Allouch
http://www.illicotravel.com