Hi David,
comments inlined ...
On Fri, Dec 1, 2017 at 4:23 PM, David Lloyd <david.lloyd(a)redhat.com> wrote:
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
I guess you meant introduction of "deprecated" attribute / element in
"urn:jboss:module:1.7" schema for module and module-alias elements?
I'd say <deprecated/> element would be better fit here because we
could specify the following optional attributes on it:
* "forRemoval" = "true" // Indicates whether the module or module
alias is
subject to removal in a future version
* "since" = "12.0" // The version in which the annotated module or
module
alias became deprecated
* finally <deprecated/> element might contain text describing reason why
module or module alias have been deprecated
Elaborating this idea further JBoss-Modules library should print warnings
to the console if
deprecated module or module-alias is loaded.
• 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
Deprecated modules might become alias modules of newly introduced modules.
• 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.
I'd say it's very unlikely but yes, it's still a possibility.
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.
Hopefully it will not be necessary.
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!
Overall it's very reasonable proposal.
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Rio