[
https://issues.apache.org/jira/browse/GROOVY-11896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18073949#comment-18073949
]
ASF GitHub Bot commented on GROOVY-11896:
-----------------------------------------
paulk-asert commented on PR #2429:
URL: https://github.com/apache/groovy/pull/2429#issuecomment-4259575345
@jonnybot0 I initially thought just to bring in half of your first branch -
let duplicate imports from modules be treated the same as duplicates from star
imports. And in fact changed (locally) the PR branch to have that. But the
order from the module imports isn't deterministic from the JDK APIs, so in fact
what you have in the first branch is exactly what we need as the smallest bump
from what I had. We have GROOVY-11916 for the package-private anomaly. I wonder
whether we should take this opportunity (via another issue) to give an error
for the multiple static import ambiguity case too. It would be breaking but I
imagine easy for folks to understand.
> Support module import declarations
> ----------------------------------
>
> Key: GROOVY-11896
> URL: https://issues.apache.org/jira/browse/GROOVY-11896
> Project: Groovy
> Issue Type: New Feature
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
>
> In Java, _module import declarations_ allow you to import all exported
> packages of a module with a single statement. It was introduced as a preview
> feature in Java 23 ([JEP 476|https://openjdk.org/jeps/476]) and finalized in
> Java 25 ([JEP 511|https://openjdk.org/jeps/511]).
> The syntax is as follows:
> {code:java}
> import module java.base; // Java
> {code}
> h3. Implementation highlights
> * Grammar extended with a dedicated import module <qualifiedName>
> alternative (no .* or as alias — rejected at parse time)
>
>
> * Modules resolved via ModuleFinder.compose(ofSystem(),
> classpathModuleFinder()) — system/JDK modules first, then modular JARs on the
> compilation classpath
>
> * Explicit JPMS modules (with module-info.class) import all unqualified
> exports; automatic modules (with Automatic-Module-Name manifest entry) import
> all packages
>
> * Default imports and existing star imports are skipped to avoid redundant
> resolution
>
>
> * module remains usable as an identifier (context-sensitive keyword, like
> record/sealed)
>
>
> Passing test scenarios:
> {code}
>
>
>
> // System module — JDK classes available without individual imports
> import module java.base
>
>
>
> LocalDate date = LocalDate.now()
> CountDownLatch latch = new CountDownLatch(1)
>
>
>
>
> // System module — java.sql
>
>
>
> import module java.sql
> assert Connection.name == 'java.sql.Connection'
>
>
>
> assert DriverManager.name == 'java.sql.DriverManager'
>
>
>
>
> // JPMS module from classpath (module-info.class)
>
>
>
> import module org.junit.jupiter.api
>
>
>
> assert Test.name == 'org.junit.jupiter.api.Test'
>
>
>
> assert DisabledIf.name == 'org.junit.jupiter.api.condition.DisabledIf'
>
>
>
>
> // Automatic module from classpath (Automatic-Module-Name in MANIFEST.MF)
>
>
>
> import module org.apache.groovy.jmx
>
>
>
> assert GroovyMBean.name == 'groovy.jmx.GroovyMBean'
>
>
>
>
>
>
>
> // Unknown module — compile error
> import module no.such.module // fails: "Unknown module: no.such.module"
>
>
>
>
>
>
>
> // Star/alias not permitted with module imports — parse error
>
>
>
> import module java.base.* // fails
>
>
>
> import module java.base as jb // fails
>
>
>
>
>
>
>
> // 'module' still works as an identifier
> def module = 'hello'
>
>
>
> assert module.toUpperCase() == 'HELLO'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
