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

21PARTAGES

6  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de _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.
2  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 08/10/2013 à 10:21
@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...

Citation Envoyé par Gugelhupf Voir le message
Et pour finir le cast est théoriquement couteux.
Théoriquement... En pratique je doute que ce soit vraiment le cas.

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

Citation Envoyé par Gugelhupf Voir le message
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++
1  0 
Avatar de hwoarang
Membre chevronné https://www.developpez.com
Le 18/10/2013 à 9:36
Citation Envoyé par Gugelhupf Voir le message
je n'ai pas cherché à décompiler le bytecode d'une classe contenant une classe Anonyme (je ne sais pas si le bytecode décompilé contient une classe locale à la place d'une classe Anonyme)
Oui, ca crée bien une classe locale. De memoire, elle a le nom de la classe mere + $N avec N => numéro de la classe anonyme (pour le cas ou il y en aurait plusieurs).

Citation Envoyé par Gugelhupf Voir le message
Pour moi une classe locale ça ne sert vraiment pas à grand chose...
Ca peut etre utile pour ne pas exposer certaines données. Par exemple, c'est sympa pour des classes de stockage de données locales à la classe.

Citation Envoyé par Gugelhupf Voir le message
PS: En fait, je parle du cas où si on devait casser le backward compatibilty de Java. D'où le remplacement de nom de méthode comme getRuntime() (singleton) par getInstance() ou getSingleton(), ou la sucre pour println().
Sur le fond, je pense aussi qu'un getInstance aurait été un choix plus heureux. Mais bon, ca me parait un peu léger comme raison pour casser la compatibilité ascendante.

Citation Envoyé par Gugelhupf Voir le message
Je n'ai jamais vraiment compris la différence entre "out" et "err", si ce n'est que "err" indique explicitement qu'il s'agit d'un message d'erreur...
En fait, ca n'utilise pas la meme sortie. En pratique, dans l'IDE ou dans une console, ca sort tout à la suite (quoique parfois, c'est quand meme entremelé). Mais en fait, System.err sort sur la sortie erreur et System.out sur la sortie standard. On peut par exemple rediriger l'un et l'autre vers 2 fichiers differents. Ou bien jeter l'un et pas l'autre (pour rediriger la sortie standard, c'est 1> et pour la sortie erreur, c'est 2> ).
1  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 04/11/2013 à 11:38
Citation Envoyé par Gugelhupf Voir le message
Alors juste une petite parenthèse, après avoir essayé les méthodes wait() et notify() de la classe Object dans un modèle producteur / consommateur, je trouve que ça fait un peu goto.
Oui clairement !
Comme le goto cela semble tout simple et facile à faire, mais il faut rester bien carré et stricte sous peine de vite faire n'importe quoi !

Citation Envoyé par Gugelhupf Voir le message
Quels seraient vos préconisations pour créer un modèle producteur / consommateur sans utiliser les méthodes wait() et notify() ?
Depuis Java 5 il y a l'API de concurrence qui permet (entre autres) de gérer cela de manière propre et simple via les BlockingQueue.
Les méthodes offer()/take() permettent respectivement d'offrir ou de récupérer une valeur depuis différents threads...

A noter que Java 6 ajoute la notion de BlockingDeque (la même chose mais dans les deux sens) et Java 7 les TransferQueue (qui permettent aux producteurs d'attendre qu'un consommateur récupère leurs valeurs avant de continuer)

a++
1  0 
Avatar de Traroth2
Membre chevronné 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...
0  0 
Avatar de 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.
0  0 
Avatar de 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...
0  0 
Avatar de _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.
0  0 
Avatar de 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++
0  0 
Avatar de 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.
0  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web