<div dir="ltr"><div>Hi David,<br><br></div> comments inlined ...<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 1, 2017 at 4:23 PM, David Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi everyone, I want to outline a brief plan for the next couple steps<br>
towards a better alignment between JBoss Modules and Java 9.<br>
<br>
In Java 9, the platform classes are divided up into modules; the core set being:<br>
<br>
java.base java.compiler java.datatransfer<br>
java.desktop java.instrument java.jnlp<br>
java.logging java.management java.management.rmi<br>
java.naming java.prefs java.rmi<br>
java.scripting java.security.jgss java.security.sasl<br>
java.smartcardio java.sql java.sql.rowset<br>
java.xml java.xml.crypto<br>
<br>
In addition, the <a href="http://java.se" rel="noreferrer" target="_blank">java.se</a> module re-exports many of these.<br>
<br>
As a first step towards alignment, it seems to me that we need to<br>
introduce the ability for modules to create module dependencies on<br>
these module names. However, unless we want to require Java 9 from<br>
now on, the names must also work on Java 8.<br>
<br>
So, I plan to follow this approximate plan:<br>
<br>
• Introduce a new PlatformModuleLoader in to JBoss Modules JDK-specific code<br>
◦ On Java 9+, this loader will create modules from the<br>
corresponding JPMS platform module set<br>
◦ On Java 8, this loader will create "system" modules from the<br>
path sets which comprise the contents of these modules, possibly<br>
including some "jdk.*" modules which are equivalent between Java 8 and<br>
Java 9<br>
• Update the LocalModuleLoader to pre-delegate module searches to<br>
PlatformModuleLoader<br>
• Remove "java" from the "system packages list"<br>
• Bring these changes in to WildFly Core<br>
• Deprecate the "javax.api", "sun.jdk", etc. modules, and also APIs<br>
which use a different-than-standard name like "javax.sql.api", replace<br>
their system dependency content with regular re-export dependencies on<br>
platform modules<br></blockquote><div><br></div><div>I guess you meant introduction of "deprecated" attribute / element in</div><div>"urn:jboss:module:1.7" schema for module and module-alias elements?</div><div>I'd say <deprecated/> element would be better fit here because we</div><div>could specify the following optional attributes on it:</div><div> * "forRemoval" = "true" // Indicates whether the module or module alias is subject to removal in a
future version</div><div> * "since" = "12.0" // The version in which the annotated module or module alias became deprecated</div><div> * finally <deprecated/> element might contain text describing reason why module or module alias have been deprecated<br></div><div><br></div><div>Elaborating this idea further JBoss-Modules library should print warnings to the console if <br></div><div>deprecated module or module-alias is loaded.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
• Deprecate and replace other modules whose names are standardized but<br>
different than ours, such as "java.corba", "java.transaction",<br>
"java.xml.bind", etc., with delegations to modules with the standard<br>
name<br></blockquote><div><br></div><div>Deprecated modules might become alias modules of newly introduced modules.<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
• Remove the "system" dependency type from the "urn:jboss:module:1.7" schema<br>
<br>
One of the remaining unknowns is that there is only one Java 9<br>
platform family in the wild right now, and it's OpenJDK-based. Other<br>
vendors might introduce a different set of "jdk.*" modules, for<br>
example, which might mean that the Java 8 emulation code for that<br>
platform family may have to be updated. I consider this risk to be<br>
mitigable.<br></blockquote><div><br></div><div>I'd say it's very unlikely but yes, it's still a possibility. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It may also be necessary to have a compatibility mode or flag to<br>
automatically add "<a href="http://java.se" rel="noreferrer" target="_blank">java.se</a>" as a module dependency, or perhaps to<br>
re-add the "java" package prefix to the system package set, depending<br>
on how compatibility shapes up in the end.<br></blockquote><div><br></div><div>Hopefully it will not be necessary. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I hope to achieve this work in JBoss Modules 1.7; this would probably<br>
be the last significant change before I start moving towards .Final.<br>
So, if you have any feedback on this idea, please let me know here<br>
ASAP. Thanks!<br></blockquote><div><br></div><div>Overall it's very reasonable proposal.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
- DML<br>
<br>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a></font></span></blockquote></div><br></div><div class="gmail_extra">Rio</div></div></div></div>