Discussion :

[Nissa Comet]

Le projet Jigsaw officiellement repoussé à Java 9, la modularisation attendra 2015
Mais une proposition d'amélioration de Java 8 prépare le terrain


Le projet Jigsaw, dont le but est la mise en place d'un système de modules et la mise en œuvre de modularité pour la plate-forme Java SE, a été prévu à l’origine pour Java 7. Il a été reporté ensuite à Java 8 et vient d'être officiellement repoussé à Java 9, prévue pour 2015.

Ce report est la conclusion d’une proposition de l’architecte en chef du Groupe de plate-forme Java chez Oracle, le dénommé Mark Reinhold. Dans son blog, Reinhold fait savoir que les avis sur sa proposition ont été partagés, mais la décision finale devait revenir au groupe d’experts Java SE 8 (JSR 337). Après avoir longuement étudié la proposition de Reinhold, la majorité de ce groupe d’experts l’a accepté.

Il n'y aura donc ni système de modules ni modularité pour Java 8, mais l’architecte énonce qu’il y a beaucoup d'avancés à accomplir en Java 8 si on veut passer à une plate-forme entièrement modulaire pour Java 9.
D’ailleurs, afin de faciliter cette transition, une nouvelle proposition d'amélioration a été soumise (JEP162). Elle apporte quelques modifications sur Java 8 telles que la dépréciation et la suppression de certaines API.

Par la même occasion, Mark Reinhold parle de sa proposition JEP 161 : « j'ai déjà suggéré que l'on considère un sous-ensemble de profils qui permettent des configurations compactes de la plate-forme SE, qui puissent être construits et déployés. JEP 161 énonce une proposition initiale spécifique pour ces profils ».

En attendant donc un système de modules, cette proposition permettra à des applications qui ne requièrent que des parties de la plateforme de n'emporter que le sous-ensemble d'un profil donné. Cela permettra d'économiser les ressources, notamment sur les petits appareils et les systèmes embarqués.


Détails du projet Jigsaw
Détails de JEP161
Détails de JEP162

Source : blog de Mark Reinhold

[Traroth2]

Si j'ai bien compris, ce projet devait surtout servir dans l'optique stratégique de relancer Java dans le domaine desktop : permettre de lancer une application Java plus rapidement, par exemple sur les postes où Java n'est pas installé.
Est-ce réellement encore utile ?

Pour le reste, le serveur entre autres, entre Maven et OSGi, je ne suis pas sûr qu'on ait vraiment besoin de Jigsaw...

[Uther]

Pour le desktop, en effet, Java se traine un mauvaise réputation surtout à cause de la lourdeur que historique de son environnement. La modularité permettrait entre autre de régler ça.
La situation est peut-être dure à rattraper, mais vu ce que Oracle a investi dans JavaFX, je le vois mal jeter ça à la poubelle tout de suite.

Pour le serveur, quand je vois les usines à gaz que sont Maven et OGSi, je me dit au contraire qu'un support des modules plus léger bien intégré a l’environnement est absolument indispensable.

[_skip]

Si j'ai bien compris, ce projet devait surtout servir dans l'optique stratégique de relancer Java dans le domaine desktop : permettre de lancer une application Java plus rapidement, par exemple sur les postes où Java n'est pas installé.
Est-ce réellement encore utile ?

Pour le reste, le serveur entre autres, entre Maven et OSGi, je ne suis pas sûr qu'on ait vraiment besoin de Jigsaw...

Il y a aussi autre chose, si je me souviens bien et si le projet n'a pas trop changé depuis ses early drafts, le JDK lui-même deviendrait modulaire et ainsi cela permettrait de faciliter et d'accélérer les process d'évolution du JDK en permettant aux modules qui le composent de suivre des cycles indépendants et plus courts. En ce sens ce ne serait pas seulement pour pouvoir installer un JDK à la carte avec une application desktop, cela permettrait aussi d'aller plus vite avec les releases et de les laisser évoluer facilement de l'avant en garantissant la rétro-compatibilité de l'existant.

Sinon il est vrai que pour le reste les gains sont très liés au packaging et à la distribution. Il y a l'élimitation des problèmes liés aux résolutions de classpath qui deviendraient statiques donc instantanées et vérifiables par le packager, ça ferait moins de boulot au runtime et permettrait de créer une sorte de cache pour le lancement d'application (c'était dans les slides SUN a l'époque).

Je rejoins Uther dans le sens où je pense que cela résoud un vrai problème de java lorsqu'on a les dépendances de dépendances qui se marchent dessus entre leurs versions respectives et tout ça. Puis il suffit de voir le nombre de projets qui utilisent Maven uniquement pour la gestion des librairies et dépendances pour bien se rendre compte que la modularité est un vrai problème qui mériterait une solution générale au niveau plateforme.

Cependant pour revenir à la news de l'article, ça risque d'être 2015 pour la première release, 2016 pour avoir un truc stable et 2018 pour avoir une adoption suffisamment large...

[marc.collin]

Pour le desktop, en effet, Java se traine un mauvaise réputation surtout à cause de la lourdeur que historique de son environnement. La modularité permettrait entre autre de régler ça.
La situation est peut-être dure à rattraper, mais vu ce que Oracle a investi dans JavaFX, je le vois mal jeter ça à la poubelle tout de suite.

Pour le serveur, quand je vois les usines à gaz que sont Maven et OGSi, je me dit au contraire qu'un support des modules plus léger bien intégré a l’environnement est absolument indispensable.

La mauvaise réputation du gui de java est souvent dû au fait que les gens font des traitements long sur une action ce qui bloque l'edt au lieu d'utiliser des threads. Sans compté que le ui n'a pas trop évolué.

JavaFX va surement le remplacer?

OSGi ne s'adresse pas à n'importe quel application. Forcément pouvoir ajouter, enlever des modules à chaud par exemple est complexe.... sans compté tous les poins liés à la sécurité.

[Traroth2]

Pour le desktop, en effet, Java se traine un mauvaise réputation surtout à cause de la lourdeur que historique de son environnement. La modularité permettrait entre autre de régler ça.
La situation est peut-être dure à rattraper, mais vu ce que Oracle a investi dans JavaFX, je le vois mal jeter ça à la poubelle tout de suite.

Pour le serveur, quand je vois les usines à gaz que sont Maven et OGSi, je me dit au contraire qu'un support des modules plus léger bien intégré a l’environnement est absolument indispensable.

D'accord pour Maven et OSGi, ça reste perfectible. Mais pour JavaFX, je ne suis pas sûr que la techno ait vraiment beaucoup d'avenir, en tout cas sur le web. Après, pour du vrai client lourd, la lourdeur réelle ou supposée de Java est quand même vachement moins problématique.