[
https://issues.apache.org/jira/browse/GROOVY-11896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18072744#comment-18072744
]
ASF GitHub Bot commented on GROOVY-11896:
-----------------------------------------
jonnybot0 commented on PR #2429:
URL: https://github.com/apache/groovy/pull/2429#issuecomment-4226969271
Overall, I agree that following Java's example seems more prudent than
Scala's.
I suspect that treating module imports as a distinct thing from static star
imports, at least at some level in the AST, might be prudent. That could be
because I never fully recovered from the psychic damage I took in the OSGi salt
mines. π
That caveat aside, it does seem like there's something from the module
imports JEP that we're not supporting: Transitive dependencies across modules
(as described in [JEP 476](https://openjdk.org/jeps/476)).
> The ability to import at the level of modules would be especially helpful
when APIs in one module have a close relationship with APIs in another module.
This is common in large multi-module libraries such as the JDK. For example,
the
[java.sql](https://docs.oracle.com/en/java/javase/22/docs/api/java.sql/module-summary.html)
module provides database access via its java.sql and javax.sql packages, but
one of its interfaces,
[java.sql.SQLXML](https://docs.oracle.com/en/java/javase/22/docs/api/java.sql/java/sql/SQLXML.html),
declares public methods whose signatures use interfaces from the
javax.xml.transform package in the
[java.xml](https://docs.oracle.com/en/java/javase/22/docs/api/java.xml/module-summary.html)
module. Developers who call these methods in java.sql.SQLXML typically import
both the java.sql package and the javax.xml.transform package. To facilitate
this extra import, the java.sql module depends on the java.xml module
[transitively](https://dev.java/learn/modules/implied-readability/), so that a
program which depends on the java.sql module depends automatically on the
java.xml module.
Unless I have made an error, the existing branch does not do this. I've
added a test to my fork (see
https://github.com/apache/groovy/commit/301582fa4d7337f8eff7643ec3cd05e68e4e20e5)
that demonstrates the issue.
This is part of what makes me think we may well need specific semantics for
the AST of module imports. There are additional expectations built into the JEP
that make me think we'd need some specific things to handle them properly.
> 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)
