Moving JBoss Modules towards Java 9 integration

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Moving JBoss Modules towards Java 9 integration

David Lloyd-2
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moving JBoss Modules towards Java 9 integration

Richard Opalka
In reply to this post by David Lloyd-2
Hi David,

   comments inlined ...

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

Rio

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev