Discussion :

[Arsene Newman]

Des ingénieurs d’Oracle proposent d’étendre Java avec des types intermédiaires
à mi-chemin entre les classes et les types primitifs

« Codé comme une classe, fonctionne comme un entier », voilà la devise de trois ingénieurs d’Oracle pour améliorer le langage Java. En effet, Brian Goetz, John Rose et Guy Steele viennent de publier le premier draft de leur proposition qui s’intitule State of the Values .

Leur proposition qui est encore à ses balbutiements vise à étendre le langage Java et la JVM avec une nouvelle catégorie de type appelée Value types qui devrait s’inscrire à mi-chemin entre les types primitifs et les classes. Le but de la manœuvre est de créer de nouveaux types qui seraient codés comme une classe et qui bénéficieraient des mécanismes qui lui sont spécifiques comme l’encapsulation, tout en offrant de meilleures performances en termes de mémoire utilisée et de CPU que les classes.

Les trois instigateurs de cette proposition appuient leur idée avec un constat simple : les objets font appel à la notion d’identité de l’objet qui est là en premier lieu pour permettre la mutabilité et le polymorphisme, ce qui a un cout important sur les performances du langage et de la JVM.

Toutefois, dans certains cas, l’utilisateur code une classe qui s’affranchit de la notion d’identité de l’objet. Par exemple, l’utilisateur définit en premier lieu une classe Point qui représente un point sur un plan 2D, en sachant que cette dernière ne sera pas « castée » en un autre objet. Il devient intéressant de l’avoir comme un Value Types.

Enfin, il est important de noter que cette proposition peut ouvrir la voie à pas mal d’améliorations pour le langage Java comme le soulignent les trois ingénieurs. Cela permettrait notamment de définir certains nombres mathématiques qui ne sont pas encore présents comme les nombres complexes ou permettre le support de certains types natifs et spécifiques aux processeurs modernes, sans oublier un tas d’autres améliorations telles que notées dans leur proposition.

Source : State of the Values

Et vous ?

Qu’en pensez-vous ?

Pensez-vous que cette proposition peut être bénéfique au langage ? Pourquoi ?

[Gugelhupf]

C'est peut-être un début pour essayer de rendre Java un langage full object, les variables primitives Java deviendraient peut-être des classes, et peut-être que les Wrapper ne seront plus utilisés (j'ai lu quelques articles dans lequel on parle d'un Java 9 qui casse le backward compatibily...).
Bien sur coté performance il y aura certainement un impact négatif.

L'avantage des "value class", c'est qu'on pourra peut-être simplifier l'utilisation des objets mutables (je pense à BigInteger et BigDecimal). Et peut-être ainsi étendre l'utilisation de la technologie Java dans le domaine des banques et assurances, dans lequel le COBOL est encore (et toujours) utilisé.

La question que je me pose est : devrait-t-on utiliser le mot-clé "new" pour instancier une "value class" ?
Pour moi c'est un mot clé qui devrait justement être réservé aux "vraies" classes Java, dont les objets passent par copie de référence, et dont les méthodes sont polymorphes. Pourtant dans l'exemple du lien ils le font avec la "value class" Point.

[Voyvode]

C'est peut-être un début pour essayer de rendre Java un langage full object[…]

C'est effectivement un des grands objectifs d'Oracle pour les prochaines versions.

Bien sur coté performance il y aura certainement un impact négatif.

Rendre objet les types primitifs tout en conservant leur performance me semble justement l'intérêt (et le défi) de ce type spécial.

Et peut-être ainsi étendre l'utilisation de la technologie Java dans le domaine des banques et assurances, dans lequel le COBOL est encore (et toujours) utilisé.

[blague méchante/]COBOL existe encore là-bas parce que ces grippe-sous ne veulent pas payer de véritables développeurs. [/blague méchante]

[Gugelhupf]

Les développeurs COBOL sont des vrais développeurs, mais... d'une autre époque on va dire... Et puis il y a :

• des milliards de lignes de codes déjà fait en COBOL
• des employés qui ne savent faire que du COBOL
• des partenariats avec IBM

Comment remplacer cela par une autre solution du jour au lendemain ? Ce n'est tout bonnement pas possible. De plus, il me semble que :

• niveau performance, ça doit surement être presque du même niveau qu'un binaire du C pour la conso CPU & mémoire.
• certaines banques ont déjà mis en place des outils graphiques pour le développement (proche du diagramme d'activité UML), cela génère ensuite du script COBOL qui sera ensuite compilé et exécuté par le mainframe.

Pour en revenir au sujet, je sais que ce projet n'est qu'à ses balbutiements mais, au lieu d'avoir deux mots-clés pour créer une "value type" (ou "value class"):

Code :

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

final __ByValue class Point { ...

Ils devraient plutôt faire usage du mot-clé "struct". Bien sur sa signification n'aura pas la même chose qu'en C ou C++, un peu comme l'a fait C# pour sa version du struct.

Je pense qu'une "value type" devrait pouvoir hériter d'une autre "value type", d'après eux ce n'est pas possible car :

Code :

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

Can a concrete value class extend another value type? No. (Because concrete value classes are final.)

Histoire de mutabilité...

Puis pour l'instanciation d'une "value type", ne pas utiliser le mot-clé "new" :

Code :

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

1
2
3
decimal salary1; // pas d'argument, constructeur par défaut
decimal salary2(); // ou bien
decimal salary3(100, 2);

Un peu comme en C++, sans le risque de confusion avec la déclaration de prototype de fonction.

[la.lune]

C'est peut-être un début pour essayer de rendre Java un langage full object, les variables primitives Java deviendraient peut-être des classes, et peut-être que les Wrapper ne seront plus utilisés (j'ai lu quelques articles dans lequel on parle d'un Java 9 qui casse le backward compatibily...).
Bien sur coté performance il y aura certainement un impact négatif.

Pour ce qui est le fait de la mort des types primitifs c'est déjà tranché pour Java 10 et non 9, mais ça ne veut pas dire qu'on aura à faire des new pour déclarer des objets. Mais ce qui est sûr ce qui veulent entamer une chose pareil voient le vrai gain, mais pas pour faire juste pour faire beau.

Personnellement je ne vois pas d'impacte négatif au contraire je vois une très bonne chose car ça éviterait des casting insensé et permettre la généricité sur des "type primitif" comme vous savez qu'en Java on peut pas faire List<int> , du coup on fera forcement List<Interer> et des casting implicite ou explicites se passent, ou appel de méthodes pour manipuler les valeurs.

Surtout actuellement avec l'API Stream qu'on tend à éliminer les boucles d'itération sur les tableaux au profit de la programmation fonctionnelle et parallèle il faudra forcement une vraie innovation sur les types primitifs, car la manipulation des types primitifs avec Stream passent par les Wrappers, alors Java 10 permettra des gain en performance.

C'est peut-être un début pour essayer de rendre Java un langage full object

Les Value types si on comprend bien le challenge ils n'ont rien n'avoir avec le fait de transformer les types primitifs en en Objet. Au contraire ça va dans le sens contraire, on veut réduire et simplifier la manière d'utilisation de certains objets comme des valeurs primitifs et bien les organiser au niveau de la mémoire encore des gain.

J'avais pensé à côté de la plaque pour les exemples que j'avais donné

[Cyäegha]

A vue de nez, ça me fait un peu penser à ce qui se fait en Scala (sauf qu'Oracle pourrait pousser à implémenter des optimisations pour ce genre de chose directement dans la JVM). En Scala, la hiérarchie des types différencie aussi les "value types", qui héritent du type AnyVal (ce sont, en particulier, tous les types qui peuvent être représentés par des types primitifs dans la JVM), et les classes qui héritent de ValueRef (un alias de java.lang.Object).

Mais AnyVal et AnyRef héritent tous deux du type Any, qui définie les méthodes comme toString, equals ou hashcode - donc les "value types" se comportent comme n'importe quels objets au niveau du code source, sans qu'on ait besoin de savoir si, dans le bytecode, ils seront représentés par des types primitifs (chaque fois que c'est possible) ou wrappés dans des objets (quand c'est nécessaire) - c'est le boulot du compilateur.

Du coup, on peut écrire (en indiquant explicitement les types, même si ce n'est pas obligatoire) :

Code :

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

1
2
3
4
5
 
val i: Int = 1 + 1 // "i" et "1" seront des types primitifs dans le bytecode : pas de perte de performance ici
val j: Boolean = i.equals(2) // On peut manipuler i comme n'importe quel objet si besoin, donc appeler une de ses méthodes
val k: BigInt = BigInt(1) + BigInt(1) // En fait, l'opérateur "+" à la première ligne était aussi lisible comme un appel
                                      // de méthode sur un objet, même si ça ne sera pas le cas dans le bytecode

L'avantage des "value class", c'est qu'on pourra peut-être simplifier l'utilisation des objets mutables (je pense à BigInteger et BigDecimal). Et peut-être ainsi étendre l'utilisation de la technologie Java dans le domaine des banques et assurances, dans lequel le COBOL est encore (et toujours) utilisé.

Je pense que tu voulais dire "des objets immutables".

Sinon, la différence de comportement entre objets et types primitifs est effectivement assez énervante en Java (comparé à des langages comme Scala ou C#) - devoir utiliser l'opérateur "+" pour un int mais la méthode "add" pour un BigInt, sous prétexte que leur implémentation est différente, n'a pas vraiment de sens... Mais il y a d'autres possibilités intéressantes indiquées dans le lien, comme les tuples ou les types Optional ou Choice (tiens, là aussi des choses qui existent en Scala ).

Pour remplacer le COBOL, par contre, oublie - de toutes façons, le problème n'est pas de savoir quel langage est le plus adapté, mais de savoir qu'il y a une montagne de code COBOL qui fonctionne déjà dans toutes les banques.

[la.lune]

Sinon, la différence de comportement entre objets et types primitifs est effectivement assez énervante en Java (comparé à des langages comme Scala ou C#) - devoir utiliser l'opérateur "+" pour un int mais la méthode "add" pour un BigInt, sous prétexte que leur implémentation est différente, n'a pas vraiment de sens... Mais il y a d'autres possibilités intéressantes indiquées dans le lien, comme les tuples ou les types Optional ou Choice (tiens, là aussi des choses qui existent en Scala ).

Mais je voulais demandé ce que tu reproche réellement aux primitifs en Java, d'abord int peut se comporter comme un Integer qui est normalement un objet et l'autre un type primitif ce qui fait qu'on peut faire:

Code Java :

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

1
2
3
4
5
6
7
  int a=new Integer(3)+new Integer(6); 
    long r=new Long(200_000_0000)+3L;
     Integer i=23+2;
     boolean b=i.equals(25);//true
     int g=0b0101_1110_10101;//3029
     Integer m=g+10;//3029
     int z=12_000 +new Integer("2334");

Mais pour ce qui est des types comme BigInteger il faut comprendre que pour manipuler des littéraux qui représentent des nombres au delà de la capacité des types primitifs existants ça ne va même pas compiler, le plus grand entier c'est un long, qui est le Long.MAX_VALUE==9223372036854775807L alors écrire un nombre dépassant cela ne va même pas compiler je ne peux pas écrire:

Code :

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

 long l=2334714582546254672783472523565263528736753752635287367537L;

car cela n'est pas une valeur primitive valie. Mais je peux écrire

Code :

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

1
2
3
 BigInteger b=new BigInteger("2334714582546254672783472523565263528736753752635287367537");
BigInteger bb = new BigInteger(new byte[]{2,3,3,4,7,1,4,5,8,2,5,4,6,2,5,4,6,7,2,7,8,3,4,7,2,5,2,3,5,6,5,2,6,3,5,2,8,7,3,6,7,5,3,7});
b.add(bb)

Ici les calculs passent pas décomposition des nombres car le processeur est incapable de faire un calcul sur ces nombres directement, c'est un problème des systèmes dans tous les langages de programmation on s'expose au même problème, ça n'a rien n'avoir avec Java. Ainsi, il n'existe pas un constructeur BigInteger(int) pas de possibilité de faire new BigInteger(123) car ça n'a pas de sens de faire appel à un constructeur de BigInteger si c'est pour manipuler un int ou un long, la limite c'est la limite que supporte un long.

Alors à quoi ça sert vraiment de faire pour des BigInteger: b+b1 alors que ça serait forcement un surcharge d’opérateur vu que il n y a pas vraiment de calcul sur des BigInteger et BigDecimal, moi je me demande comment en Scala on va pouvoir insérer un grand nombre dans un BigInt alors que ni la JVM ni .Net que Scala est compilé vont pouvoir faire un calcul pareil, impossible, à moins que le compilateur va compiler b+b1 en b.add(b1) vu qu'ils sont tous les deux des BigInt

[thelvin]

devoir utiliser l'opérateur "+" pour un int mais la méthode "add" pour un BigInt, sous prétexte que leur implémentation est différente, n'a pas vraiment de sens...

Et justement, ça n'a rien à voir avec les implémentations. C'est une question de définition du langage.

Il y a en Java, exactement 8 types primitifs. Pas moins, pas plus. 8. Pour certains d'entre eux, ça a un sens de prévoir un opérateur d'addition : double, float, long, int, short, byte et char. Pour d'autres, ça n'a pas de sens : boolean. Donc l'opérateur d'addition a été prévu pour les 7 types primitifs connus pour lesquels il a un sens, et pas pour les autres.

BigInteger, par contre, est une classe. Une classe comme une autre. Il y a en Java un nombre indéfini de classes, ça change tout le temps. De manière générale, par exemple dans le cas chien + facture, un opérateur d'addition n'a pas de sens entre deux types classe, ou objet de manière générale. Il n'y a donc pas eu tentative d'insérer dans le langage un opérateur qui, par définition, ne peut pas marcher. Les méthodes, en revanche, sont des mécanismes qu'on peut appliquer à tous les types objet, donc si on a un type additionnable, il suffit de lui donner une méthode add().
Il a été décidé pour le langage Java que la classe BigInteger, n'est pas si intéressante pour mériter d'être un cas particulier de sorte d'avoir un opérateur qui marche qu'avec elle. Même si ça avait été le cas, ça n'aurait pas résolu le besoin de nouvelles classes de nombres additionnables, dont Java ne pourrait pas deviner que ce sont des cas particuliers.
Certaines classes, en Java, sont spéciales. Les classes wrappers. La classe String. La classe Object, ascendante de tous les types objets. Il y a une méthode qui est un xas particulier, aussi, getClass(). Mais pas BigInteger ni son add().

[Stellar7]

Lecteurs du vendredi, bonjour !

C'est peut-être un début pour essayer de rendre Java un langage full object

est-ce vraiment l'objectif ?

<mode Troll /ON>
Tout ce boulot revenir à Smalltalk ?
<mode Troll /OFF>

[tchize_]

[B]Par exemple, l’utilisateur définit en premier lieu une classe Point qui représente un point sur un plan 2D, en sachant que cette dernière ne sera pas « castée » en un autre objet.

Dommage le choix de l'exemple

Point, Point2D.Float, Point2D.Double, tous étendent Point2D et le typecasting arrive entre Point2D et Point2D.Double, parfois

[la.lune]

Dommage le choix de l'exemple

Point, Point2D.Float, Point2D.Double, tous étendent Point2D et le typecasting arrive entre Point2D et Point2D.Double, parfois

C'est ça aussi que je trouve intéressant s'ils bossent pour définir des règles de conversion implicites entre les nombres, car rien de m'empêche de faire double a=2; ou int b=2; float c=a;
Mais le challenge serait sur la manière dont ils vont compiler et manipuler ces nombres au fond de la mémoire car si au préalable j'ai un point Point dont x et y sont des double alors forcement ils vont réserver de l'espace mémoire de deux double même si en fait on va introduire de simples float ou même des byte .

Par là on voit l’intérêt de Java 10, s'ils offrent une souplesse sur la manipulation de valeur primitifs pas juste transformer les valeur en wrapper, là la valeur sera stocké telle qu'il est, pas question de réserver de l'espace mémoire qui ne sera pas utilisé. Déjà on se demande pourquoi autant de types primitifs dont les développeurs ne savent pas s'en servir vraiment. Rare que tu trouve des code par ici par là on utilise les types short ou byte vaut mieux avoir partout des références sur le tas, avec une inférence de type très fort.

[tchize_]

je peux pas te dire pour short, mais des que tu lit des fichiers, tu tape dans le byte

Pour le Point, si il y a plusieurs type différent, c'est justement parce la mathématique entre le double et le int n'est pas la même. Avec des int je peux faire a == b. Avec des doubles, c'est dangereux!

[la.lune]

Pour le Point, si il y a plusieurs type différent, c'est justement parce la mathématique entre le double et le int n'est pas la même. Avec des int je peux faire a == b. Avec des doubles, c'est dangereux

Je comprend pas le danger côté mathématique, je sais qu'en programmation 3.0 n'est pas 3, mais mathématiquement sont les même. Par définition si x est un nombre réel alors elle est une quantité dont la représentation donne décimal x=n+0.d1d2d3... ou n un nombre entier et d1,d2,d2 des entier compris entre 0 et 9.
En effet 5.23= 5+0.23, ainsi 3.0 = 3+0.0 or 0.0=0 et 3+0=3, donc 3.0=3. Et selon la regèle de construction des réel R=N U Z U Q U R\Q . Et la relation suivante est toujours vraie N⊂Z⊂Q⊂R car Z={N}U{-N}; Q=Z/Z donc Q={N}U{-N}/{N}U{-N} seulement Q⊄R\Q, mais R\Q⊂R . Déjà en programmation on n'a pas un type qui représente des irrationnels tout court ni des rationnels non incluant les entiers relatifs Q\Z. Une chose est sûr que si je dis que soit n un entier, alors pas possible d'avoir un nombre à virgule dans n, sémantiquement oui, mais je n'arrive pas à saisir le danger de faire a==b entre doubles.

[thelvin]

mais je n'arrive pas à saisir le danger de faire a==b entre doubles.

Parce qu'avec un nombre de bits finis on ne peut représenter qu'un ensemble fini de valeurs différentes, or, entre n'importe quels deux réels il existe une infinité de réels compris entre ces deux réels. Conclusion : les réels ne peuvent pas être représentés avec des bits. Dans la mesure où le but des double est de faire comme si on pouvait quand même, cela signifie que les représentations et les calculs seront approchés, pas exacts.

Et si, en calculs exacts, on s'attend à trouver égalité entre deux nombres calculés, en calculs approchés les mêmes nombres calculés ont de grandes chances de finir différents du fait des approximations.

[tchize_]

Je comprend pas le danger côté mathématique, je sais qu'en programmation 3.0 n'est pas 3, mais mathématiquement sont les même. Par définition si x est un nombre réel alors elle est une quantité dont la représentation donne décimal x=n+0.d1d2d3... ou n un nombre entier et d1,d2,d2 des entier compris entre 0 et 9.

Billet ici qui explique pourquoi il ne faut pas utiliser == ou != avec des nombres flottants:

http://randomascii.wordpress.com/201...-2012-edition/

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public static void main(String[] args) {
 
		double f = 0.1;
		double sum;
		sum = 0;
 
		for (int i = 0; i < 10; ++i)
		    sum += f;
		double product = f * 10;
		System.out.printf("sum = %1.15f, mul = %1.15f, mul2 = %1.15f\n",
		        sum, product, f * 10);
		System.out.println ("sum == product?"+(sum==product));
 
	}

Même si mathématiquement le code est correct en considérant que sum==product, informatiquement, c'est faux. Et quand on met == entre deux double, c'est, en général, qu'on assume que deux calculs ont donné le même résultat sur le plan mathématique, pas informatique. Et du coup, ça peut bugger là où on pense que c'est bon.

[Bono_BX]

<mode Troll /ON>
Tout ce boulot revenir à Smalltalk ?
<mode Troll /OFF>

<mode Troll /ON>
Ou comment prouver encore une fois l'obsolescence de JAVA ...
<mode Troll /OFF>

[bouye]

"utiliser des objets comme des primitifs"

Hum, en fait c'est une manière déguisée de dire qu'on va pouvoir définir nos propres opérateurs (aux moins ceux de base) si j'ai bien saisi ?
Car sinon je ne vois pas trop l'intérêt.

*sous réserve que le langage aille effectivement dans cette direction.

[thelvin]

Non, c'est pas du tout l'idée.
Le problème avec les types objet, c'est qu'ils ont tout un tas de métadonnées qui prennent de la place et obligent le CPU à faire plein de déréférencement. Bref, Integer comparé à int, c'est lent, ça bouffe de la mémoire et les tableaux sont pas contigus. D'où l'intérêt de int par rapport à Integer.

Mais parfois, on aimerait avoir ce même genre de performances pour d'autres types que juste un entier. Genre un vertex, ou l'exemple de Point2D.
Un peu comme, quand on bosse avec les images, une couleur RGBA est représentée par un int pour raisons de performances... Alors que ce serait bien pratique si c'était sous forme de red, green, blue, alpha ou tout en même temps. Mais avec des classes ce serait bien trop lourd.

[bouye]

Ok donc retour à la struct ou à l'union... Pas vraiment convaincu que le "slogan publicitaire" qu'il aient choisi soient le bon dans ce cas.
Ce qui m'ennuie en tant que programmeur ce n'est pas tant que les données de BigInteger ou de Color ou de mes classes ne soient pas contiguës mais plutôt le fait que la syntaxe objet ajoute de la lourdeur là où il n'y a pas besoin d'en avoir. Après bien sur c'est de leur faute d'avoir repoussé la possibilité de faire des opération sur les Big* plusieurs fois d'affilée...

Après bien sur je ne cracherai pas sur une amélioration de performances du à un "stockage de données contiguë" coté client,mais c'est plutôt coté serveur que ça prend tout son sens que ça sera vraiment apprécié et donc ça n'a pas vraiment d’intérêt de faire porter les exemples sur Point2D ou Color.
Ca peut avoir son intérêt coté mobile/smart devices, mais encore faudrait-il que Sun et Google s'entendent pour qu'Android passe le pas vers cette hypothétique future version et on sait tous que ce n'est pas près d'arriver. Ça restera confidentiel sur les autres plateformes tant qu'Oracle n'arrivera pas à faire que Java soit plus souvent utilisé sur iOs (et comme ils ont préféré se désister sur bébé sur la communauté, ça risque de prendre du temps).

[atha2]

Ca peut avoir son intérêt coté mobile/smart devices, mais encore faudrait-il que Sun et Google s'entendent pour qu'Android passe le pas vers cette hypothétique future version et on sait tous que ce n'est pas près d'arriver

Sait-on jamais, je pensais la même chose et Java 7 est arrivé sur android (quand sort Java 8 mais c'est déjà ça). Au vu des procès entre Oracle et Google, j'avais fait une croix dessus. A priori une syntaxe n'est pas brevetable (les procès portait surtout sur les API et 5 lignes de code basiques). A voir si le comportement lié à une syntaxe peut être breveté.

Pour en revenir au sujet, je sais que ce projet n'est qu'à ses balbutiements mais, au lieu d'avoir deux mots-clés pour créer une "value type" (ou "value class"):

Code :

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

final __ByValue class Point { ...

Ils devraient plutôt faire usage du mot-clé "struct". Bien sur sa signification n'aura pas la même chose qu'en C ou C++, un peu comme l'a fait C# pour sa version du struct.

le __ByValue et le __MakeValue ne sont que des placeholder pour un mot-clé qui reste à définir. J'aime bien struct Pour le __MakeValue, les propositions (non exhaustives) sont :

Code :

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

1
2
3
4
 
decimal salary = new decimal(100, 2);
decimal salary = decimal(100, 2);
decimal salary = (100, 2);

Puis pour l'instanciation d'une "value type", ne pas utiliser le mot-clé "new" :

Code :

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

1
2
3
decimal salary1; // pas d'argument, constructeur par défaut
decimal salary2(); // ou bien
decimal salary3(100, 2);

Un peu comme en C++, sans le risque de confusion avec la déclaration de prototype de fonction.

La première proposition n'est pas possible en java, sinon on n'a plus la distinction entre un pointeur et une valeur (en C++ on déclare un pointeur decimal * salary(0); ). Pour la deuxième (qui en C++ est une déclaration de fonction ) et la troisième, le problème c'est que, par exemple, pour le retour anonyme et il faudra faire comme en C++ cad :

Code :

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

return decimal(100, 2)

Et là on se retrouve avec l'impression d'appeler une fonction (d’ailleurs un analyseur syntaxique n'est pas capable de faire la différence) et non de créer un objet (en JS c'est là même chose, mais c'est une autre philosophie ). Même si j'adore le C++, je n'ai pas envie de me retrouver avec la complexité de la syntaxe du C++ en Java. A mon sens, la syntaxe de Java doit rester compréhensible sans le contexte (localisation, symbole), rester simple.