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

Le , par Hinault Romaric, Responsable .NET
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 ?


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


 Poster une réponse

Avatar de Traroth2 Traroth2 - Expert éminent sénior https://www.developpez.com
le 05/09/2013 à 14:05
Il leur aura fallu plus de 5 ans pour réaliser que leur proposition n'était pas viable. Ca commence à ressembler à l'Arlésienne...
Avatar de Logan Mauzaize Logan Mauzaize - Rédacteur/Modérateur https://www.developpez.com
le 13/09/2013 à 17:35
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.
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 23/09/2013 à 11:25
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.
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 06/10/2013 à 23:48
Citation Envoyé par _skip  Voir le message
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...
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 07/10/2013 à 9:39
Citation Envoyé par Gugelhupf  Voir le message
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.
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 07/10/2013 à 9:54
Citation Envoyé par Gugelhupf  Voir le message
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

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

Citation Envoyé par Gugelhupf  Voir le message
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++
Avatar de tchize_ tchize_ - Expert éminent sénior https://www.developpez.com
le 07/10/2013 à 11:07
Citation Envoyé par _skip  Voir le message
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.
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 07/10/2013 à 11:30
Citation Envoyé par tchize_  Voir le message
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%.
Avatar de tchize_ tchize_ - Expert éminent sénior https://www.developpez.com
le 07/10/2013 à 11:38
Citation Envoyé par _skip  Voir le message
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é.
Avatar de tchize_ tchize_ - Expert éminent sénior https://www.developpez.com
le 07/10/2013 à 11:40
Citation Envoyé par _skip  Voir le message
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 :/
Offres d'emploi IT
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)
Architecte sécurité des systèmes d'information embarqués H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Spécialiste systèmes informatiques qualité et référent procédure H/F
Safran - Ile de France - Colombes (92700)

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