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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.