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

[Andrig Miller]

One thing we need to measure, as we move towards full Java 9 support, is
what the impact is on MetaSpace.  In theory, having the JDK modularized
could improve our MetaSpace usage, but I'm not sure.  Certainly, we don't
want it to get worse.

Andy

On Fri, Dec 1, 2017 at 8:23 AM, 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
> • 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev




-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171201/139d0331/attachment.html