Uploaded image for project: 'JBoss Modules'
  1. JBoss Modules
  2. MODULES-372

JDK 11 - module not found java.se

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 1.9.1.Final
    • 1.8.5.Final
    • None

      When trying to start up WFLY with JDK 11 (using standalone.sh, I am getting this error:

      org.jboss.modules.ModuleNotFoundException: java.se
      	at org.jboss.modules.Module.addPaths(Module.java:1266)
      	at org.jboss.modules.Module.link(Module.java:1622)
      	at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
      	at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
      	at org.jboss.modules.Main.main(Main.java:437)
      

      Output of java -version:

      openjdk version "11-ea" 2018-09-25
      OpenJDK Runtime Environment 18.9 (build 11-ea+21)
      OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
      

            [MODULES-372] JDK 11 - module not found java.se

            I took a stab at this in https://github.com/Ladicek/jboss-modules/commits/emulated-java-se-module and would appreciate any comments. Especially if this approach has any chance of being accepted

            The one question I wasn't able to answer on my own is: should the org.jboss.modules.emulated.java.se module have its own distinct name, or should it be called java.se. I opted into the former option, as it seems less invasive. The latter option would be more transparent, but might have unintended consequences that I'm not aware of.

            With the current name, I was able to confirm with Thorntail that adding --add-modules java.se is no longer necessary, but only after I changed the definition of the javax.api module from WildFly (as that refers directly to the java.se name).

            Ladislav Thon added a comment - I took a stab at this in https://github.com/Ladicek/jboss-modules/commits/emulated-java-se-module and would appreciate any comments. Especially if this approach has any chance of being accepted The one question I wasn't able to answer on my own is: should the org.jboss.modules.emulated.java.se module have its own distinct name, or should it be called java.se . I opted into the former option, as it seems less invasive. The latter option would be more transparent, but might have unintended consequences that I'm not aware of. With the current name, I was able to confirm with Thorntail that adding --add-modules java.se is no longer necessary, but only after I changed the definition of the javax.api module from WildFly (as that refers directly to the java.se name).

            David Lloyd added a comment -

            Correct. We could re-aggregate the relevant modules by hand.

            David Lloyd added a comment - Correct. We could re-aggregate the relevant modules by hand.

            Ladislav Thon added a comment - - edited

            My understanding is that it's JBoss Modules who implicitly add the dependency on java.se to [almost] all modules. While the java.se module isn't "available" by default, this module is nothing but an aggregator of other modules that are "available" by default (I think – please correct me if I'm wrong here). So technically, JBoss Modules could either add an implicit dependency on all these modules, or create another aggregating module and add a dependency on that. (Do I even make sense here?)

            Ladislav Thon added a comment - - edited My understanding is that it's JBoss Modules who implicitly add the dependency on java.se to [almost] all modules. While the java.se module isn't "available" by default, this module is nothing but an aggregator of other modules that are "available" by default (I think – please correct me if I'm wrong here). So technically, JBoss Modules could either add an implicit dependency on all these modules, or create another aggregating module and add a dependency on that. (Do I even make sense here?)

            George Gastaldi added a comment - - edited

            dlloyd@redhat.com how about falling back to a JBoss Module if the java.se JDK module cannot be found? (With a flag to enable this behavior)

            George Gastaldi added a comment - - edited dlloyd@redhat.com how about falling back to a JBoss Module if the java.se JDK module cannot be found? (With a flag to enable this behavior)

            Sorry I accidentally misplaced the parameter. I've now changed the appclient.sh directly to

            eval \"$JAVA\" $JAVA_OPTS \
            --add-modules java.se \
            -cp "$CLASSPATH" \ ...

            This seems to work

            Wolfgang Mayer (Inactive) added a comment - Sorry I accidentally misplaced the parameter. I've now changed the appclient.sh directly to eval \"$JAVA\" $JAVA_OPTS \ --add-modules java.se \ -cp "$CLASSPATH" \ ... This seems to work

            David Lloyd added a comment -

            Could you please elaborate?

            David Lloyd added a comment - Could you please elaborate?

            This work around does not work on Java HotSpot

            Wolfgang Mayer (Inactive) added a comment - This work around does not work on Java HotSpot

            Thanks for the workaround (I've verified it on OpenJDK build 11.0.1). Just a thing, the correct parameter to add is --add-modules java.se

            Francesco Marchioni (Inactive) added a comment - Thanks for the workaround (I've verified it on OpenJDK build 11.0.1). Just a thing, the correct parameter to add is --add-modules java.se

            David Lloyd added a comment -

            I'd like to figure out a "real" fix at some point, so let's leave this open for now.

            David Lloyd added a comment - I'd like to figure out a "real" fix at some point, so let's leave this open for now.

            Kabir Khan added a comment -

            dlloyd@redhat.com Should this be closed? As I believe we have worked around this as recommended in issues like:

            Kabir Khan added a comment - dlloyd@redhat.com Should this be closed? As I believe we have worked around this as recommended in issues like: https://issues.jboss.org/browse/WFLY-10937 https://issues.jboss.org/browse/WFLY-10811 https://issues.jboss.org/browse/WFLY-10772

              ropalka Richard Opalka
              manovotn Matěj Novotný
              Archiver:
              rhn-support-ceverson Clark Everson

                Created:
                Updated:
                Resolved:
                Archived: