Summary

Based on the experiences with the previous round of preview, we propose the following updates to this feature:

• requires transitive java.base; will be permitted,
• the java.se module will be enhanced to include requires transitive java.base;,
• types imported using a module import will be shadowed by types imported using on-demand imports, in addition to being shadowed by single-element imports.

The module imports feature will re-preview.

Problem

During the previous round of preview, two issues have been identified:

First, doing import module java.se; imports all Java SE packages, except for packages from the java.base module. This seems confusing and unexpected, as users may rightfully expect that import module java.se; will import all types from java.base. (Please see https://mail.openjdk.org/pipermail/amber-spec-experts/2024-July/004184.html)

Second, having code like:

import module java.base;
import module java.desktop;
...
List l; //ambiguous

the only way to disambiguate was either to use a single-element import (i.e. import java.util.List;) or a fully-qualified name. This seems to be too restricted. (Please see https://bugs.openjdk.org/browse/JDK-8341289)

Solution

To solve the first problem, two changes are proposed:

• requires transitive java.base; will be permitted. This is currently not permitted for classfiles version 54 and later. This sub-feature will also be covered by the preview handling, i.e. general classfiles using this feature will be marked as preview classfiles.
• the module-info for the java.se module will be enhanced to include requires transitive java.base;. The java.se module specifically, and any other java.* module will be considered to be participating in preview with regards to this sub-feature, and will not be marked as a preview classfile.

To solve the second problem the following is proposed: types imported using a module import will be shadowed by types imported using on-demand imports, in addition to being shadowed by single-element imports.

As a consequence, to solve the above ambiguity problem, one can write:

import module java.base;
import module java.desktop;
import java.util.*;
...
List l; //not-ambiguous

Specification

The definition of the java.se module is enhanced as follows:

diff --git a/src/java.se/share/classes/module-info.java b/src/java.se/share/classes/module-info.java
index 81b1bd3cb8aa9..9a2704660b7b9 100644
--- a/src/java.se/share/classes/module-info.java
+++ b/src/java.se/share/classes/module-info.java
@@ -23,6 +23,8 @@
  * questions.
  */

+import jdk.internal.javac.ParticipatesInPreview;
+
 /**
  * Defines the API of the Java SE Platform.
  *
@@ -38,7 +40,9 @@
  * @moduleGraph
  * @since 9
  */
+@ParticipatesInPreview
 module java.se {
+    requires transitive java.base;
     requires transitive java.compiler;
     requires transitive java.datatransfer;
     requires transitive java.desktop;

The JLS draft is attached as "Module Import Declarations (Second Preview) - JLS.pdf" and is also available for convenience here: https://cr.openjdk.org/~gbierman/jep494/jep494-20241024/specs/module-import-declarations-jls.html

The JVMS draft is attached as "Module Import Declarations (Second Preview) - JVMS.pdf" and is also available for convenience here: https://cr.openjdk.org/~gbierman/jep494/jep494-20241024/specs/module-import-declarations-jvms.html