Uploaded image for project: 'CCC Migration Project'
  1. CCC Migration Project
  2. CCC-8154956

Module system implementation refresh (4/2016)

XMLWordPrintable

    • high
    • Hide
      The implication of the policy for root modules described in JEP 261 is that the CORBA module and the modules shared with Java EE will not be resolved by default. More specifically, the following modules will not be resolved:

      java.activation
      java.annotations.common
      java.corba
      java.transaction
      java.xml.bind
      java.xml.ws
      java.se.ee (aggregates the EE modules)

      As these modules will not be resolved then the types in these modules will not be visible. It will "appear" as if these types do not exist when compiling or running.

      This change is motivated by the strong need to avoid confusing average developers that put JAR files on the classpath with types in the same packages as these modules. For example, if a developer puts the jsr305.jar on the class path containing defect detection annotations. With JDK 9 today then these annotations will not be loaded because the package javax.annotation is in module java.annotations.common. The module system does not allow packages to be split between system modules and the class path. The only reason it worked in JDK 8 and older is because types in this package were split, some were loaded by the boot loader, some by the app loader.

      This change is an incompatible change but it comes with an easy workaround. The modules have not been removed, they are in the runtime image and can be resolved means of the `-addmods` option. For example, if there is a legacy application using CORBA then it would need to be compiled or run with `-addmods java.corba`.

      In summary, this is disruptive change that will need to be well documented in the JDK 9 documentation. We currently have EA builds available with this change and are using it to shake out issues and get early feedback.
      Show
      The implication of the policy for root modules described in JEP 261 is that the CORBA module and the modules shared with Java EE will not be resolved by default. More specifically, the following modules will not be resolved: java.activation java.annotations.common java.corba java.transaction java.xml.bind java.xml.ws java.se.ee (aggregates the EE modules) As these modules will not be resolved then the types in these modules will not be visible. It will "appear" as if these types do not exist when compiling or running. This change is motivated by the strong need to avoid confusing average developers that put JAR files on the classpath with types in the same packages as these modules. For example, if a developer puts the jsr305.jar on the class path containing defect detection annotations. With JDK 9 today then these annotations will not be loaded because the package javax.annotation is in module java.annotations.common. The module system does not allow packages to be split between system modules and the class path. The only reason it worked in JDK 8 and older is because types in this package were split, some were loaded by the boot loader, some by the app loader. This change is an incompatible change but it comes with an easy workaround. The modules have not been removed, they are in the runtime image and can be resolved means of the `-addmods` option. For example, if there is a legacy application using CORBA then it would need to be compiled or run with `-addmods java.corba`. In summary, this is disruptive change that will need to be well documented in the JDK 9 documentation. We currently have EA builds available with this change and are using it to shake out issues and get early feedback.
    • Java API, add/remove/modify command line option
    • SE

      Summary

      Module system implementation refresh (4/2016)

      Problem

      This CCC tracks updating the module system and tools introduced by JEPs 200/260/261/282 via CCC-8142968.

      In summary:

      1. JEP 261 has been updated to define the root modules to use when compiling code in the unnamed module, and at runtime, the root modules when the main class is loaded from the class path.

      2. The jar and jmod tools are updated to define command-line options for recording the hashes of packaged modules. The new options replace a command-line option introduced by the original integration.

      3. API changes

        • javax.lang.model.util.Elements defines two new methods.
        • Clarification to java.lang.reflect.Module.toString

      There are several other changes in this update but these other changes don't relate to supported interfaces and so do not need to be listed here.

      Solution

      Change javac and the VM to align with the policy for root modules described in JEP 261.

      Update the jar and jmod tools to drop the --hash-dependencies option and replace it with the --hash-modules option.

      Add two methods to javax.lang.model.util.Elements.

      Specification

      1. Updated policy on root modules, from JEP 261:
      
      "When the compiler compiles code in the unnamed module, or the java launcher is invoked and the main class of the application is loaded from the class path into the unnamed module, then the default set of root modules is computed as follows:
      
      The java.se module is a root, if it exists. If it does not exist then every java.* module on the upgrade module path and among the system modules that exports at least one package, without qualification, is a root.
      
      Every non-java.* module on the upgrade module path and among the system modules that exports at least one package, without qualification, is also a root."
      
      
      2. Drop the --hash-dependencies option from the `jar` and `jmod` tools. 
      
      For the `jmod` tool, add the a hash sub-command and two additional options:
      
        hash      - Records hashes of tied modules
      
        --dry-run                          Dry run of hash mode    
      
        --hash-modules <pattern>           modules to be hashed, given as a      
                                             PATTERN 
      
      For the `jar` tool, add one new option:
      
            --hash-modules=PATTERN Compute and record the hashes of modules 
                                   matched by the given pattern and that depend upon
                                   directly or indirectly on a modular jar being
                                   created or a non-modular jar being updated
      
      
      In both cases, PATTERN is a regular expression defined by the java.util.regex.Pattern engine, a syntax similar to Perl.
      
      
      
      
      3. The attached specdiffs has the API changes.

            alanb Alan Bateman
            alanb Alan Bateman
            Jonathan Gibbons, Mandy Chung
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: