Developpez.com

Plus de 2 000 forums
et jusqu'à 5 000 nouveaux messages par jour

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

Le , par Arsene Newman, Expert éminent sénior
« 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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Gugelhupf Gugelhupf - Modérateur http://www.developpez.com
le 08/05/2014 à 17:14
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.
Avatar de Voïvode Voïvode - Membre émérite http://www.developpez.com
le 08/05/2014 à 19:14
Citation Envoyé par Gugelhupf  Voir le message
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.

Citation Envoyé par Gugelhupf  Voir le message
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.

Citation Envoyé par Gugelhupf  Voir le message
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]
Avatar de Gugelhupf Gugelhupf - Modérateur http://www.developpez.com
le 08/05/2014 à 20:02
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
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
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
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.
Avatar de la.lune la.lune - Membre chevronné http://www.developpez.com
le 08/05/2014 à 20:40
Citation Envoyé par Gugelhupf  Voir le message
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.

Citation Envoyé par Gugelhupf  Voir le message
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é
Avatar de Cyäegha Cyäegha - Membre régulier http://www.developpez.com
le 08/05/2014 à 20:40
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
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
Citation Envoyé par Gugelhupf  Voir le message
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.
Avatar de la.lune la.lune - Membre chevronné http://www.developpez.com
le 08/05/2014 à 22:53
Citation Envoyé par Cyäegha  Voir le message
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
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
 long l=2334714582546254672783472523565263528736753752635287367537L;
car cela n'est pas une valeur primitive valie. Mais je peux écrire
Code : Sélectionner tout
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
Avatar de tchize_ tchize_ - Expert éminent sénior http://www.developpez.com
le 08/05/2014 à 23:13
Citation Envoyé par Arsene Newman  Voir le message
[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
Avatar de la.lune la.lune - Membre chevronné http://www.developpez.com
le 08/05/2014 à 23:42
Citation Envoyé par tchize_  Voir le message
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.
Avatar de tchize_ tchize_ - Expert éminent sénior http://www.developpez.com
le 08/05/2014 à 23:56
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!
Avatar de thelvin thelvin - Modérateur http://www.developpez.com
le 09/05/2014 à 1:20
Citation Envoyé par Cyäegha  Voir le message
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().
Offres d'emploi IT
Architecte big data H/F
Safran - Ile de France - Magny-les-Hameaux (78114)
Data scientist H/F
Safran - Ile de France - Magny-les-Hameaux (78114)
Ingénieur sécurité des systèmes d'information drone (2 postes à pourvoir) H/F
Safran - Ile de France - Éragny (95610)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil