Discussion :

[Hinault Romaric]

Oracle lance une nouvelle tentative pour intégrer la modularité à Java
une nouvelle implémentation du projet Jigsaw voit le jour

Java n’est pas prêt à être doté d’un système de modules grâce au projet Jigsaw. Mark Reinhold, architecte en chef du groupe de la plateforme Java chez Oracle vient d’annoncer le redémarrage du projet.

Le projet Jigsaw vise essentiellement à découper la bibliothèque d’exécution de base de Java en différents modules. Cela devrait permettre à une machine virtuelle Java (JVM) de fonctionner sans le support de certains packages de base.

Après un travail préliminaire qui avait abouti à une proposition en 2008, le système de modules du projet Jigsaw allait être l’une des principales innovations de Java 7. Le projet a été reporté ensuite à Java 8, puis finalement, Oracle a annoncé sa sortie avec Java 9, annoncé pour 2015.

Les principales raisons de ces reports sont des problèmes techniques liés à la compatibilité. La mise au point d’un système de modularité dans le JDK est un véritable défi, à cause des dépendances qui existent entre les packages. Par exemple, java.beans à une dépendance vers java.applet, qui dépend à son tour de java.awt.

Face aux difficultés rencontrées, Mark Reinhold vient d’annoncer la création d’un nouveau prototype de Jigsaw pour explorer une approche simplifiée pour la réalisation des objectifs de ce projet.

La nouvelle implémentation devra relever comme principal défi la mise au point d’une modularité sans un mode « module » distinct comme c’est le cas avec la version actuelle (qui a été la source de plusieurs incompatibilités), ceci sans faire de résolution de dépendances (caractéristique offerte par des outils comme Maven, Ivy ou Gradle).

Les principales décisions de conception porteront également sur la mise sur pied d’un système de modules statiques (comme Maven) ou dynamiques (comme OGSI), la représentation des métadonnées des dépendances dans des fichiers et la nécessité d’utiliser des dépendances déclaratives (comme Maven).

Le nouveau projet est basé sur un clone de l’actuel Jigsaw implémenté dans Java 8. Toutes les décisions de conception peuvent encore être changées pendant le processus de développement.


Source : message de Mark Reinhold


Et vous ?

Que pensez-vous du projet Jigsaw et des multiples problèmes rencontrés avec celui-ci ?

[Traroth2]

Il leur aura fallu plus de 5 ans pour réaliser que leur proposition n'était pas viable. Ca commence à ressembler à l'Arlésienne...

[Logan Mauzaize]

Sans la modularisation de la JVM, je ne vois aucun intérêt à Jigsaw, sauf peut-être la visibilité inter-package (si elle est maintenue). Reste tout de même à voir à quoi ca va ressembler au final.
D'ailleurs il y a une description du fonctionnement de ce "nouveau" Jigsaw ?


Je me demande quand ils auront le courage de couper la rétrocompatibilité. A la publication de chaque version majeure (voir mineure), on croise les doigts pour qu'il y ait un minimum d'impact sur nos codes.
Au pire ils pourraient essayer de se limiter à deux version antérieures. Vu le rythme des publications, ca permettrait d'introduire quelques modifications dans le bytecode (et autres) pour avoir un support minimaliste des futures fonctionnalités.

[_skip]

Cela me conforte qu'on aurait bien plus besoin d'un java 2 incompatible que d'un java 1.8, 1.9, 1.250. C'est vraiment affligeant d'entendre que l'on est coincé avec jigsaw à cause de quelques packages en peau de casserole, enfin ça montre aussi que le JDK lui même est sacrément emmêlé. J'ai peur qu'on se retrouve avec un maven au rabais 6 ans après, la modularité et les dépendances sont un important problème dans les projets java qui mériterait une vraie solution plutôt qu'un compromis.

[Gugelhupf]

mériterait une vraie solution plutôt qu'un compromis.

Le backward compatibility force à créer des compromis en Java. Les annotations qui disparaissent après compilation, de même que pour les generics qui disparaissent et laissent place à un cast d'Object, les syntaxes sucrées pour le try-with-ressources et lambdas...

[_skip]

Le backward compatibility force à créer des compromis en Java. Les annotations qui disparaissent après compilation, de même que pour les generics qui disparaissent et laissent place à un cast d'Object, les syntaxes sucrées pour le try-with-ressources et lambdas...

Je sais bien, et c'est pour cela que je pense de plus en plus qu'un java 2 serait une solution alléchante. Pas forcément pour les gros comptes du JCP dont le seul but est de sécuriser leurs propres investissements mais pour les nouveaux projets.
Cette backward compatibility au nom de laquelle on a tant sacrifié, je ne suis pas sûr qu'on l'ait vraiment toujours dans la pratique.

[adiGuba]

Les annotations qui disparaissent après compilation,

Les annotations ne disparaissent pas après la compilation.
Par défaut elles sont bien stockées dans le fichier *.class, mais inaccessible via l'API de reflection. Cela permet de les utiliser dans les outils de manipulation de classes.

Mais on peut changer ce comportement pour via l'annotation @Retention

les syntaxes sucrées pour le try-with-ressources et lambdas...

Les lambdas ne sont pas tout à fait du sucre syntaxique.
Cela implique pas mal de changement au niveau de la JVM...

Mais sinon je ne vois pas le mal à utiliser du sucre syntaxique.
Quel problème y-a-t-il avec cela pour le try-with-ressources ??? Je n'en vois aucun !

Le backward compatibility force à créer des compromis en Java.

En même temps cela force à réellement à l'impact d'une fonctionnalité, et d'en mesurer chaque aspect avant de les implémenter.

Les Generics sont perdus à la compilation, mais offre à 95% les mêmes fonctionnalités tout en permettant une rétrocompatibilité avec le code existant.
Je doute que la migration existante aurait été si rapide si la totalité des librairies utilisant l'API de Collection serait devenu obsolète...



Perso, pour avoir suivi quelques discussions sur les mailing-lists du projet "Coins" ou sur les lambda, j'ai été surpris de voir les réflexions prise en compte avant l'intégration d'une features, en particulier sur les impacts et implications que cela pourrait apporter.


Après l'évolution du langage peut sembler plus lente par rapport à .NET par exemple, mais personnellement elle me semble aussi plus réfléchi par certains points...


a++

[tchize_]

Je sais bien, et c'est pour cela que je pense de plus en plus qu'un java 2 serait une solution alléchante. Pas forcément pour les gros comptes du JCP dont le seul but est de sécuriser leurs propres investissements mais pour les nouveaux projets.

Même les nouveaux projet ont besoin de la compatibilité. Aujourd'hui, rares sont les projets qui ne réutilisent pas spring, hibernate, quartz, apache commons et d'autres librairies, open source ou closed source. Si tu refuse la compatibilité avec l'existant, tu peux presque être sur que ta techno ne sera pas adoptées facilement. Et si tu ne me crois pas, regarde javafx. Sur papier, c'est génial. Mise à jour automatique de l'interface en fonction des données, composants graphiques et démos magnifique. Mais concrètement, pour le java fx 1, tu ne pouvais pas incorporer de code java, fallait tout recoder. Résultat, j'attends toujours de voir de belles applications desktop en javafx. Les gens préfèrent se baser sur netbeans ou eclipse RCP, apache pivot ou simplement swing. Il sacrifient les belles interface pour pouvoir utiliser les outils existants.

[_skip]

Même les nouveaux projet ont besoin de la compatibilité. Aujourd'hui, rares sont les projets qui ne réutilisent pas spring, hibernate, quartz, apache commons et d'autres librairies, open source ou closed source. Si tu refuse la compatibilité avec l'existant, tu peux presque être sur que ta techno ne sera pas adoptées facilement. Et si tu ne me crois pas, regarde javafx. Sur papier, c'est génial. Mise à jour automatique de l'interface en fonction des données, composants graphiques et démos magnifique. Mais concrètement, pour le java fx 1, tu ne pouvais pas incorporer de code java, fallait tout recoder. Résultat, j'attends toujours de voir de belles applications desktop en javafx. Les gens préfèrent se baser sur netbeans ou eclipse RCP, apache pivot ou simplement swing. Il sacrifient les belles interface pour pouvoir utiliser les outils existants.

Alors ça c'est clair... Mais je pense que ça fonctionnerait justement parce que ça s'appelle java et que les grands frameworks s'empresseraient de s'aligner.

Cependant il y a, je pense, pas besoin d'aller aussi loin. Si tu regardes du côté de ceylon, ils ont une modularité au niveau langage (pas pour le JDK hein, ça c'est un gros module) et des reified generic (au sens ou les types sont dispos au runtime) et ça tourne sur la JVM et l'interop avec les librairies pur java est possible.
C'est pas source compatible en revanche puisque c'est un autre compilateur. Donc je me dis que si un langage pour la JVM arrive quasiment à avoir les features demandées sans toucher au code de la JVM (bon c'est pas *TOUS* les éléments prévus par jigsaw mais déjà assez pour tacler une bonne série de problèmes) je vois pas pourquoi un Java 2 avec un JDK 2 ne le pourrait pas.

La backward compatibility, tu l'as au niveau de la source, en revanche avec le paquet de services J2EE qui exigent une JVM spécifique pour fonctionner normalement, je suis pas sûr qu'on l'ait à 100%.

[tchize_]

Alors ça c'est clair... Mais je pense que ça fonctionnerait justement parce que ça s'appelle java et que les grands frameworks s'empresseraient de s'aligner.

Je n'ai pas vu beaucoup de grand framework s'aligner sur javafx....

Jeter pour recommencer de 0 c'est une décision de programmeur, parce que, qu'on le veuille ou non, c'estp lus facile d'écrire du code que de lire le code qu'un autre à écrit. Ce n'est pas une décision rationnelle d'un point de vue maintenance et fiabilité.

[tchize_]

et ça tourne sur la JVM et l'interop avec les librairies pur java est possible.
C'est pas source compatible en revanche puisque c'est un autre compilateur.

On a jamais dit que ça devait être 100% source compatible, pour autant que tu puisse zapper d'un compilo 7 à 8 et vice versa suivant le type de code que tu veux compiler. Java a rajouté des mots clés (enum par exemple) ce qui empeche certaisn vieux codes de compiler sous java 5 sans être remaniées. Ce n'est pas possible de compiler un code avec des generics sous java 4. Ce qu'il faut c'est une compatibilité binaire. Ce que tu décrit, c'est exactement ce que tu refuse plus haut: quelque chose de compatible. Je ne comprend pas trop ta logique :/

[adiGuba]

Cependant il y a, je pense, pas besoin d'aller aussi loin. Si tu regardes du côté de ceylon, ils ont une modularité au niveau langage (pas pour le JDK hein, ça c'est un gros module) et des reified generic (au sens ou les types sont dispos au runtime) et ça tourne sur la JVM et l'interop avec les librairies pur java est possible.

Il y a des choses qui sont plus facile à faire sur un nouveau langage que sur un langage qui a plus de 15 ans...

Le gros problème de la modularité, c'est justement les APIs standards.
Si elle ne sont pas bien "séparé" cela ne servira à rien. D'ailleurs il y a déjà eu un gros travail de ce coté là dans Java 8.




Sinon franchement : vous avez souvent été gêné par la non-réification des Generics ?


a++

[Gugelhupf]

@adiguba

Les lambdas ne sont pas tout à fait du sucre syntaxique.

Lambda -> On dirait du sucre syntaxique pour les classes Anonyme
Moi je ne suis pas contre du tout contre la sucre syntaxique. Le try-with-ressources c'est bien, j’inciterais même les utilisateurs à migrer vers Java 7 pour utiliser cette syntaxe.

Les Generics sont perdus à la compilation, mais offre à 95% les mêmes fonctionnalités

C'est justement à ce niveau là qu'il y a des compris... où sont passé les 5 autres pourcents ? L'impossibilité de créer ou d'instancier des tableaux génériques par exemple.


En fait, en entreprise, je me suis rendu compte que les décideurs étaient très frileux de migrer d'une version à une autre de Java ("Java 7 est sorti il y a un an ? Ben tiens on va migrer à Java 6"). Mais au fond ça ne sert à rien de s'inquiéter car j'ai l'impression qu'un bytecode Java 7 pourrait fonctionner avec un environnement Java 1.4 (ou antérieur)

[adiGuba]

Lambda -> On dirait du sucre syntaxique pour les classes Anonyme

Justement non ce n'est pas du sucre syntaxique, puisque cela ne crée pas une classe anonyme.
En fait cela crée une méthode private, qui sera appelé avec les bons paramètres via l’invocation dynamique de Java 7...

C'est justement à ce niveau là qu'il y a des compris... où sont passé les 5 autres pourcents ? L'impossibilité de créer ou d'instancier des tableaux génériques par exemple.

Ca fait partie des limitations en effet. Mais est-ce vraiment aussi problématique ?

Pour simplement pouvoir faire new T[] ou new T() plus simplement ils auraient dû casser toute la rétrocompatibilité et remplacer toutes les APIs existantes par des nouvelles ?

Sans compter l'occupation mémoire supplémentaire lié à la duplication de code que cela implique...

En fait, en entreprise, je me suis rendu compte que les décideurs étaient très frileux de migrer d'une version à une autre de Java ("Java 7 est sorti il y a un an ? Ben tiens on va migrer à Java 6"). Mais au fond ça ne sert à rien de s'inquiéter car j'ai l'impression qu'un bytecode Java 7 pourrait fonctionner avec un environnement Java 1.4 (ou antérieur)

Alors imagine un peu ce que cela aurait été si toutes les librairies utilisant l'API de Collections avaient étés pointés du doigts du jour au lendemain...


C'est ce qui s'est passé avec les Generics de C#, qui a proposé une nouvelle API de Collections (mais comme le langage était plus jeune, du coup c'était moins problématique)


a++

[tchize_]

Sans compter l'occupation mémoire supplémentaire lié à la duplication de code que cela implique...

Ca aurait été un catastrophe. On a déjà sur les grosse appli des classloader bien chargés, imaginer cela fois 3 ou 4 à cause des generics, ça m'aurais fait peur

Les generics sur les tableau: depuis que java 5 est sorti : 1 fois ça m'a posé problème, une fois en 9 an j'ai été coincé par le language..... C'est fou, c'est inadmissible (que d'autres languages ne soient pas aussi stables)

[Gugelhupf]

Ca fait partie des limitations en effet. Mais est-ce vraiment aussi problématique ?

Pour simplement pouvoir faire new T[] ou new T() plus simplement ils auraient dû casser toute la rétrocompatibilité et remplacer toutes les APIs existantes par des nouvelles ?

Pour faire new T() il faudrait utiliser les templates comme en C++ (mais le bytecode deviendrait alors plus lourd).

Ce n'est pas catastrophique non plus, mais à cause de ces compromis il n'est pas possible de déclarer un tableau générique : T[] t = new T[10];
... chose qui ne fait qu'indiquer que c'est un tableau d'une seule dimension avec 10 emplacements.

Ou bien encore, impossible de surcharger une méthode utilisant la généricité :
void methode(ArrayList<Foo> liste) { }
void methode(ArrayList<Toto> liste){ } // Impossible, "existe déjà"

Ou bien encore : ArrayList<Integer>[] list = new ArrayList<Integer>[10];
Et non il faut faire : ArrayList<Integer>[] list = new ArrayList[10];

Choses qui sont par exemple possible en C#, mais ce n'est pas le sujet. Et pour finir le cast est théoriquement couteux.

Plus haut j'avais dis que les entreprises étaient très frileuses lorsqu'il s'agissait d'effectuer migration, pourtant Java est backward compatible, donc autant en profiter pour casser la compatibilité et donner raison à leur frilosité. De toute façon à un moment donné il faudra la casser, c'est ce qui est arrivé en C# comme tu le dis, en Python 2.x à 3 et avec jQuery 1.X à 2
De plus ça permettrait surement d'ajouter des features sympas comme le mot-clé yield ou bien un équivalent d'SQL-92 (vas y Oracle ! ) comme LINQ.

[adiGuba]

@Gugelhupf : les tableaux sont dangereux car ils fonctionnent de la manière inverse des Generics : le code n'est pas typesafe à la compilation.
Toutes les vérifications sont effectuées à l'exécution, ce qui peut entrainer toutes sortes d'erreurs, contrairement aux Generics qui garantissent un code typesafe à partir du moment où la compilation passe sans erreur ni warning !

Mais dans tous les cas à la place d'un tableau la solution est d'utiliser une ArrayList<T>.

C'est drôle parce que d'un coté tu parles de casser la rétrocompatibilité, mais de l'autre tu t'accroches à vouloir utiliser des tableaux à tout prix !
Qu'aurais-tu dis si Java 5.0 aurait utiliser des Generics incompatible qui supprimait l'usage des tableaux ???




Quand au problème de surcharge, oui c'est vrai. Mais encore une fois est-ce un si gros problème que cela ?
On peut toujours renommer la méthode si la présence de deux méthodes est vraiment obligatoire.




Bref je trouve que c'est vraiment du chipotage pour peu de chose.
A mes yeux la rétrocompatibilité est bien plus importante que ces détails...

Et pour finir le cast est théoriquement couteux.

Théoriquement... En pratique je doute que ce soit vraiment le cas.

Plus haut j'avais dis que les entreprises étaient très frileuses lorsqu'il s'agissait d'effectuer migration, pourtant Java est backward compatible, donc autant en profiter pour casser la compatibilité et donner raison à leur frilosité.

Comme çà au lieu d'être simplement frileuses, les entreprises ne migreront pas du tout !

• Avec une retrocompatibilité tu peux migrer l'existant relativement facilement (car il faut malgré tout quand même tester et valider la migration).
  Ensuite tu peux utiliser les nouvelles fonctionnalités dans le "nouveau" code, et/ou faire évoluer le code existant petit à petit.
  
• Sans rétrocompatibilité, tu dois retravailler tout le code existant pour l'adapter et le migrer vers la nouvelle plateforme, avant de tester et valider la migration. Selon les changements apportées cela peut être un très gros travail qui demandera beaucoup de temps... qui impactera l'évolution des applications.

Perso lorsqu'on est passé de Java 1.4 à Java 5.0, on a eu un gros boulot pour migrer toutes nos collections vers les Generics.
Ce fut un long travail mais il a été possible petit à petit car on a pu migrer l'application AVANT, et que la modif restait compatible.
Cela aurait été beaucoup plus long si on devait changer d'API... au risque de rester sur les anciennes... voir sur du Java 1.4 tout court !

De toute façon à un moment donné il faudra la casser, c'est ce qui est arrivé en C# comme tu le dis, en Python 2.x à 3 et avec jQuery 1.X à 2
De plus ça permettrait surement d'ajouter des features sympas comme le mot-clé yield ou bien un équivalent d'SQL-92 (vas y Oracle ! ) comme LINQ.

L'ajout de fonctionnalité ne passe pas obligatoirement par des incompatibilités.

Et pour le coup le mot-clef "yield" correspond vraiment à du sucre syntaxique, puisque cela va générer un itérateur correspondant au code de la méthode...

Perso si on doit vraiment casser Java, ce serait avant tout pour lui corriger certaines de ces erreurs de jeunesses (comme les méthodes de synchronisation notify()/wait() dans la classe Object !)




a++

[Gugelhupf]

@Gugelhupf : les tableaux sont dangereux car ils fonctionnent de la manière inverse des Generics : le code n'est pas typesafe à la compilation.
Toutes les vérifications sont effectuées à l'exécution, ce qui peut entrainer toutes sortes d'erreurs, contrairement aux Generics qui garantissent un code typesafe à partir du moment où la compilation passe sans erreur ni warning !

Mais dans tous les cas à la place d'un tableau la solution est d'utiliser une ArrayList<T>.

Et si j'utilise get(int index) pour une liste, ce n'est pas aussi dangereux qu'un tableau ?

Les tableaux et les listes génériques peuvent cohabiter. Théoriquement un tableau c'est pour des emplacements de taille fixe, et les listes pour des emplacements de taille dynamique. Et puis même si avec une ArrayList<T> on peut faire tout ce qu'on a besoin de faire avec un tableau, il ne pourrait pas y avoir d'ArrayList<T> sans tableau...


EDIT : En fait je dis une bêtise pour la méthode get(int index), l'objet List doit surement avoir un attribut indiquant une intervalle de valeur possible.

[adiGuba]

Et si j'utilise get(int index) pour une liste, ce n'est pas aussi dangereux qu'un tableau ?

C'est l'implémentation d'ArrayList qui t'assure que le code sera typesafe

Tout ce que tu peux avoir avec get() c'est une erreur d'index, mais là on sort des problèmes de type et donc des Generics...

Les tableaux et les listes génériques peuvent cohabiter.

Ca dépend.
Tu peux très bien le faire avec quelques précautions, mais il reste que le code utilisant des tableaux n'est pas typesafe (c'est à dire que le compilateur ne pourra pas assurer qu'il compilera sans erreur).

Par exemple le code suivant compilera très bien avec les tableaux, mais génèrera une exception à l'exécution :

Code :

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

1
2
3
	Double[] doubleArray = new Double[10];
	Number[] numberArray = doubleArray; // OK
	numberArray[0] = new Integer(0); // ArrayStoreException

Hors l'objectif des Generics est de supprimer toutes ces erreurs à l'exécution, et de les détecter dès la compilation.
Si un code utilisant des Generics compile sans erreurs ni warnings, alors le compilateur t'assure que tu es sûr de ne pas obtenir d'erreur de typeage à l'exécution (sur le code Generics en tout cas).

Ce qu'il est impossible de faire avec les tableaux !
Les tableaux Java ne sont pas sûr du fait de leurs fonctionnement...


Pour info le code équivalent avec les Generics et les List<T> génère une erreur dès la compilation :

Code :

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

1
2
3
	List<Double> doubleList = new ArrayList<>();
	List<Number> numberList = doubleList; // ERROR
	numberList.add(new Integer(0));

Alors c'est vrai que des Generics "reified" aurait permis des tableaux de types Generics... mais cela n'aurait rien changer au fait que cela soit un code non-typesafe (et donc à l'encontre même du principe des Generics).

Théoriquement un tableau c'est pour des emplacements de taille fixe, et les listes pour des emplacements de taille dynamique. Et puis même si avec une ArrayList<T> on peut faire tout ce qu'on a besoin de faire avec un tableau, il ne pourrait pas y avoir d'ArrayList<T> sans tableau...

Les tableaux sont avant tout une facilité du langage, mais à utiliser avec précaution du fait des problèmes qu'il peuvent générer...


Et justement si c'était à refaire et qu'on puisse avoir un Java incompatible, je verrais bien les tableaux disparaitre au profit d'une éventuelle classe Array<T>...


a++

[Gugelhupf]

Ah oui en effet, après avoir vu ces exemples je comprends mieux... mais comme dit plus haut, au niveau de l'implémentation, les ArrayList (il me semble) se servent des tableaux. Il y aura toujours des tableaux, c'est un moyen d'optimiser le tri.

Et justement si c'était à refaire et qu'on puisse avoir un Java incompatible, je verrais bien les tableaux disparaitre au profit d'une éventuelle classe Array<T>...

Comme en C++11 (mais les tableaux existent toujours).