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 includerequires 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 includerequires transitive java.base;
. Thejava.se
module specifically, and any otherjava.*
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
- csr of
-
JDK-8335989 Implement JEP 494: Module Import Declarations (Second Preview)
- Resolved