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

[Richard Opalka]

Hi David,

   comments inlined ...

On Fri, Dec 1, 2017 at 4:23 PM, David Lloyd <david.lloyd at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


Rio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171204/1a6655af/attachment-0001.html