Discussion :

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

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

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.

[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

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

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

[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

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

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

[tomlev]

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

Effectivement... mais en C# le problème est détecté un peu plus tôt : le cast n'est pas valide, alors qu'en Java il l'est, puisqu'au runtime un List<Foo> et un List<Bar> sont strictement identiques.

Mais bon, c'est vrai qu'au final ça ne change pas grand chose... quels que soient les garde-fous mis en place dans le langage, il est toujours possible de se tirer une balle dans le pied

[adiGuba]

Et c'est ce qui permet la rétrocompatibilité du code...


Les deux implémentations des Generics ont leurs avantages et leurs défauts.
Je ne pense pas qu'il y ait une implémentation qui soit un meilleur choix qu'une autre. Je dirais même que les deux implémentations sont bien adaptés à leurs environnements (écosystème existant, langage, etc.).

• En Java l'incompatibilité des primitives a été compensé par une compatibilité complète avec les APIs existantes.
• En C# la duplication des API a été compensé par une compatibilité avec les primitives et surtout les types valeurs.

Non c'est juste que je vois souvent de grosses critiques envers les Generics de Java pour pas grand chose au final (si ce n'est l’incompatibilité des primitifs).
Je vois souvent parler de Generics complètement "reifié" à la C#, mais en Java cela apporterait plus de problème qu'autre chose.

Et ce choix "partiel" (Generics réifié uniquement pour les primitives/values) me semble un très bon compromis.


a++


[edit] Tiens au fait : pourquoi cette discussion est-elle dans le forum "eclipse" ?

[_skip]

A part ça, une proposition intéressante de Mr. Hibernate sur la façon de concilier les génériques et les types primitifs avec l'introduction d'un nouveau supertype "Any" qui fournirait à la fois l'abstraction sur Object et les types primitifs. Selon lui, ça éviterait de trop agir sur un système de type déjà suffisamment complexe en l'état.

Sur la mailing list:
http://mail.openjdk.java.net/piperma...er/000474.html

[adiGuba]

@_skip : la réponse de Brian Goetz est tout aussi intéressante : http://mail.openjdk.java.net/piperma...er/000475.html


a++

[_skip]

@_skip : la réponse de Brian Goetz est tout aussi intéressante : http://mail.openjdk.java.net/piperma...er/000475.html
a++

Je sais pas si tu as vu, il y a aussi la suite de l'échange sur 2015 et ça se gâte...
http://mail.openjdk.java.net/piperma...ry/thread.html

En gros, côté Goetz la réponse est "on y a déjà pensé c'est inacceptable", parce qu'Any pose des problèmes dans sa représentation en bytecode sans boxing ainsi que sur la sémantique (ce serait quelque chose de "fictif"). Du côté de Gavin King, on se demande en quoi c'est plus fictif que tout le système des génériques java qui tourne autour du "type erasure" et défend que le cas particulier qui nécessiterait du boxing pour Any est de toutes façons interdit dans la proposition actuelle. Il suggère aussi une approche différente en utilisant des unions discriminées.

A ce moment là, les réponses de Goetz ne portent malheureusement plus sur les aspects techniques et deviennent évasives, ça se résume à quelque chose du genre "votre attitude est pas constructive, on a consacré assez de temps sur le sujet et vous êtes pas en droit d'exiger plus de notre part, on n'est pas dans un monde parfait et on peut pas plaire tout le monde", plus quelques petites piques ad hominem glissées ci et là. Et effectivement, on obtient pas de réponse sur les points de Gavin King et comme ce dernier le mentionne, la proposition en ligne n'offre pas les justifications techniques qu'on souhaiterait sur la prise de position de Goetz et son équipe.

En bref, tout ceci donne l'impression que finalement, il y a finalement peu de place pour le débat. Ca me fait penser à l'époque de java7 où la communauté a été mobilisée sur des sujets divers avant de se rendre compte qu'elle jacassait dans le vide. Ca me paraît un peu con parce que ce projet valhalla machin est justement supposé exister pour débattre et échanger, à quoi ça sert d'avoir des process ouverts si c'est pour répondre aux feedbacks d'intervenants qu'on n'a pas à se justifier et qu'ils n'ont qu'à eux-mêmes proposer des patchs pour la JVM s'ils sont pas contents?

[thelvin]

Ouais enfin Goetz a déjà dit en quoi c'est plus fictif, dans la proposition de Gavin il n'y a pas de "cas particulier qui nécessiterait du boxing" c'est boxing et c'est tout, Goetz a déjà expliqué que ça va prendre du temps pour rédiger des explications complètes des choix techniques, et les unions discriminées ça fait parties des choses que la JVM ne sait pas faire comme Goetz l'a expliqué.

Alors OK c'est pas très pro de la part de Goetz de montrer à quel point il en a marre qu'on lui parle de "solutions simples" sans jamais prouver avec du concret qu'elles peuvent être mises en œuvre.
Mais on peut aussi se mettre à sa place. Si dialogue il y a, il est censé être mené avec un minimum de compétence. Comme déjà dit, ce qui est proposé là est évident, mais encore faut-il que ça soit réalisable en pratique, et si quelqu'un a une raison de le penser, ce serait tout de même la moindre des choses de prouver comment.

[_skip]

Ouais enfin Goetz a déjà dit en quoi c'est plus fictif, dans la proposition de Gavin il n'y a pas de "cas particulier qui nécessiterait du boxing" c'est boxing et c'est tout, Goetz a déjà expliqué que ça va prendre du temps pour rédiger des explications complètes des choix techniques, et les unions discriminées ça fait parties des choses que la JVM ne sait pas faire comme Goetz l'a expliqué.

Ce n'est pas exactement ce que j'ai compris de mon côté, Goetz dit effectivement qu'il n'y pas de de façon de représenter Any sans boxing, mais ce serait pas un problème

So, the first possibility, as you've intuited, is that assignment of a
primitive to Any results in boxing, as it does today when you assign a
primitive to Object.

*However*, this approach actually does not result in the problem
you've described. Consider the possible concrete instantiations of
List:

- List<Any> - boxing, like today with List<Object>
- List<Object> - same as today
- List<int> - no boxing, since we can use the same specialization
approach used in the paper

The only case which involves boxing is a case which you disallow in
the current proposal, which means that this is not worse than the
current proposal.

En gros :
List<int> pourrait satisfaire List<? extends Any> sans avoir besoin de List<? extends Object>. C'est clair que si on commence à faire des choses comme List<Any>.add(5); il y'aura du boxing.
Après, il propose 2 voies pour l'implémentation. Je vois pas ce que ça coûte de lui répondre sur le pourquoi ce n'est pas faisable puisque Goetz affirme qu'ils ont eux aussi creusé cette voie. S'il utilisait un quart des lignes de ses réponses suivantes pour expliquer ce point plutôt que sortir un discours sur le monde pas parfait, perso ça m'intéresserait.

Mais bon, je n'ai pas d'action ni chez Oracle ni chez Red hat.

[adiGuba]

Je sais pas si tu as vu, il y a aussi la suite de l'échange sur 2015 et ça se gâte...
http://mail.openjdk.java.net/piperma...ry/thread.html

Oui j'ai vu que cela dérivait par la suite... malheureusement.

Même si dans un sens je comprend les deux acteurs :

• Gavin qui voudrait plus de détail sur les problèmes de sa proposition, et qui prend mal le fait qu'elle soit rejeté d'un simple : "c'est pas possible".
• Goetz qui voudrait centrer le débat sur l'implementation choisie et non pas sur des choix différent, et qui prend mal le fait de voir quelqu'un débarqué en disant en gros : "ca c'est mieux".

Le truc c'est que hormis pour le projet Coins, les débats sur les mailing-lists ont toujours concerné une implémentation spécifique.
Les grandes lignes ont été décidé, et il est question des détails de l'implémentation.
Bref il est en général question de discuter les détails d'une implémentation plutôt que de remettre tout (ceci ayant déjà été fait auparavant).

Ca peut paraitre "arbitraire", mais en même temps il faut parfois décider de certains points pour avancer.


Par contre je ne comprend pas comment on pourrait gérer un type "Any" en raw-type qui regrouperait objets et primitives/values, puisque ces deniers sont géré différemment en mémoire...



a++