[
https://issues.apache.org/jira/browse/GROOVY-11896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18073394#comment-18073394
]
ASF GitHub Bot commented on GROOVY-11896:
-----------------------------------------
paulk-asert commented on PR #2429:
URL: https://github.com/apache/groovy/pull/2429#issuecomment-4242885938
> 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
[301582f](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.
Nice catch @jonnybot0! I updated the PR to include this ability.
> 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)
