Re: [wildfly-dev] Moving JBoss Modules towards Java 9 integration

Hi everyone, I want to outline a brief plan for the next couple steps towards a better alignment between JBoss Modules and Java 9. In Java 9, the platform classes are divided up into modules; the core set being: java.base java.compiler java.datatransfer java.desktop java.instrument java.jnlp java.logging java.management java.management.rmi java.naming java.prefs java.rmi java.scripting java.security.jgss java.security.sasl java.smartcardio java.sql java.sql.rowset java.xml java.xml.crypto In addition, the java.se module re-exports many of these. As a first step towards alignment, it seems to me that we need to introduce the ability for modules to create module dependencies on these module names. However, unless we want to require Java 9 from now on, the names must also work on Java 8. So, I plan to follow this approximate plan: • Introduce a new PlatformModuleLoader in to JBoss Modules JDK-specific code ◦ On Java 9+, this loader will create modules from the corresponding JPMS platform module set ◦ On Java 8, this loader will create "system" modules from the path sets which comprise the contents of these modules, possibly including some "jdk.*" modules which are equivalent between Java 8 and Java 9 • Update the LocalModuleLoader to pre-delegate module searches to PlatformModuleLoader • Remove "java" from the "system packages list" • Bring these changes in to WildFly Core • Deprecate the "javax.api", "sun.jdk", etc. modules, and also APIs which use a different-than-standard name like "javax.sql.api", replace their system dependency content with regular re-export dependencies on platform modules • Deprecate and replace other modules whose names are standardized but different than ours, such as "java.corba", "java.transaction", "java.xml.bind", etc., with delegations to modules with the standard name • Remove the "system" dependency type from the "urn:jboss:module:1.7" schema One of the remaining unknowns is that there is only one Java 9 platform family in the wild right now, and it's OpenJDK-based. Other vendors might introduce a different set of "jdk.*" modules, for example, which might mean that the Java 8 emulation code for that platform family may have to be updated. I consider this risk to be mitigable. It may also be necessary to have a compatibility mode or flag to automatically add "java.se" as a module dependency, or perhaps to re-add the "java" package prefix to the system package set, depending on how compatibility shapes up in the end. I hope to achieve this work in JBoss Modules 1.7; this would probably be the last significant change before I start moving towards .Final. So, if you have any feedback on this idea, please let me know here ASAP. Thanks! -- - DML _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev