[wildfly-dev] Moving JBoss Modules towards Java 9 integration
david.lloyd at redhat.com
Fri Dec 1 10:23:34 EST 2017
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
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
• Update the LocalModuleLoader to pre-delegate module searches to
• 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
• 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
• 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
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
More information about the wildfly-dev