Mark Reinhold (Architecte en Chef de Java) a annoncé la relance des efforts pour rendre Java entièrement modulaire. Cette nouvelle s'est présentée sous la forme d'un groupe de Propositions d'Amélioration Java (JEPs pour « Java Enhancement Proposals ») qui rajeunit l'initiative de modularité Java connue sous le nom du projet Jigsaw.
La vision de Reinhold s'étale sur quatre grandes JEPs dont le rôle de chacune est de fournir un aspect complet de modularité. L'effort global sera exécuté sous le projet Jigsaw, qui vise à offrir une JDK modulaire, même si le point de vue officiel d’Oracle est qu'il ne sera pas nécessairement abouti dans le cadre de Java 9 (mais si possible, il le sera). Cela peut être dû à l'expérience avec Java 8, où la modularité a été retirée de la release à un stade relativement tardif.
Malgré ce manque d'engagement ferme au niveau du calendrier Java 9, la première des JEPs modulaires est apparue au sein de l'annonce d'un groupe de caractéristiques destinées à faire partie de Java 9, tel que JEP 201 (intitulé « Modular Source Code »). En dépit de ce nom évocateur, cette JEP n’introduit pas de modularité dans un sens significatif pour un développeur d'applications Java. En fait, la version bêta de Java 9 telle qu'elle est actuellement, en cours de développement, ne possède aucune trace de modularité dans les binaires.
Au lieu de cela, cette JEP est destinée à être un jalon de plus vers la modularité, suffisamment petite et inoffensive qu'elle peut être (et a déjà été) fusionnée sous la principale OpenJDK 9. En effet, tout ce que JEP 201 compte atteindre est de modifier la disposition de l'arbre des sources OpenJDK de sorte qu'il soit désormais composé de modules.
Dans chaque module, la structure de répertoire a également été remaniée, avec l'effet secondaire que le code commun entre les systèmes d'exploitation Unix-like a été renommé en « unix » (auparavant appelé « Solaris » pour des raisons historiques).
La prochaine JEP liée à la modularité vise à décrire et définir la structure du module mais pas réellement sa mise en œuvre. La description de JEP 200 définit son objectif comme :
Définir une structure modulaire pour la JDK. Formuler des hypothèses minimales sur le système de module qui sera utilisé pour mettre en œuvre cette structure.
Ces hypothèses minimales incluent l'idée que tout module qui commence par « java » est un module standard qui sera régi par la Java Specification Requests (JSR) et fera partie de la norme Java (pour une version future de Java). En particulier, de tels modules doivent avoir une API publique portable entre les différentes implémentations Java.
Les changements que JEP 201 a introduit concernant la mise en page du code source exposent ces modules standards et apportent également le concept d'un module « jdk » pour représenter les implémentations internes qui sont spécifiques à OpenJDK/Oracle JDK.
Il y a encore beaucoup de travail qui doit se produire avant que le JRE soit modulaire et que nous voyons la fin d'un rt.jar monolithique. Un obstacle spécifique qui a causé des problèmes la dernière fois est le sous-système de chargement de classes. Dans un écosystème modulaire, les classloaders doivent être conscients des modules ; de ce fait les modules doivent devenir le principal mécanisme pour le chargement de code en un processus Java en cours d'exécution.
Il reste à voir si Oracle est en mesure d'achever les travaux d'ingénierie nécessaires pour offrir une modularité pour la livraison à temps de la version Java 9. Cependant, l'adoption d'une approche progressive ainsi que des JEPs séparées pour les différents aspects du projet sont à saluer et offrent une plus grande chance de succès par rapport aux tentatives précédentes. Les développeurs vont observer la progression du projet Jigsaw avec beaucoup d'intérêt.