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