[
https://issues.apache.org/jira/browse/GROOVY-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11916:
-------------------------------
Description:
Groovy's star import resolution (e.g., import java.util.*) currently includes
package-private classes in name resolution. On modern JDKs (9+) with the module
system, these classes cannot actually be used — attempts result in
IllegalAccessError at runtime. This can lead to confusing errors and
inconsistency with Java's behaviour where star imports only resolve public
types.
For example, import java.util.* allows def cls = TimSort to compile (resolving
the package-private java.util.TimSort), but any actual usage (instanceof,
construction, method calls) fails at runtime with IllegalAccessError.
{code:groovy}
import java.util.*
assert String.modifiers == 17
def cls = TimSort // fine
assert cls.modifiers == 0
println cls // => class java.util.TimSort
println Class.forName('java.util.TimSort') // => class java.util.TimSort
println new Object() instanceof TimSort // IllegalAccessError
{code}
Having said that is it really any different than being able to get the class
via Class.forName?
If the Java behavior is deemed correct, the fix would be to filter non-public
classes during star import resolution in ResolveVisitor, producing a clean
compile-time error instead of a runtime error. This is technically a breaking
change but only affects code that was already failing at runtime on modular
JDKs.
This also benefits the import module feature (GROOVY-11896), which expands to
star imports — filtering at the resolution level means module imports correctly
include only public types, matching Java's import module semantics.
was:
Groovy's star import resolution (e.g., import java.util.*) currently includes
package-private classes in name resolution. On modern JDKs (9+) with the module
system, these classes cannot actually be used — attempts result in
IllegalAccessError at runtime. This leads to confusing errors and inconsistency
with Java's behaviour where star imports only resolve public types.
For example, import java.util.* allows def cls = TimSort to compile (resolving
the package-private java.util.TimSort), but any actual usage (instanceof,
construction, method calls) fails at runtime with IllegalAccessError.
The fix should filter non-public classes during star import resolution in
ResolveVisitor, producing a clean compile-time error instead of a runtime
error. This is technically a breaking change but only affects code that was
already failing at runtime on modular JDKs.
This also benefits the import module feature (GROOVY-11896), which expands to
star imports — filtering at the resolution level means module imports correctly
include only public types, matching Java's import module semantics.
> Star imports should not resolve package-private types
> -----------------------------------------------------
>
> Key: GROOVY-11916
> URL: https://issues.apache.org/jira/browse/GROOVY-11916
> Project: Groovy
> Issue Type: Bug
> Reporter: Paul King
> Priority: Major
>
> Groovy's star import resolution (e.g., import java.util.*) currently includes
> package-private classes in name resolution. On modern JDKs (9+) with the
> module system, these classes cannot actually be used — attempts result in
> IllegalAccessError at runtime. This can lead to confusing errors and
> inconsistency with Java's behaviour where star imports only resolve public
> types.
> For example, import java.util.* allows def cls = TimSort to compile
> (resolving the package-private java.util.TimSort), but any actual usage
> (instanceof, construction, method calls) fails at runtime with
> IllegalAccessError.
> {code:groovy}
> import java.util.*
> assert String.modifiers == 17
> def cls = TimSort // fine
> assert cls.modifiers == 0
> println cls // => class java.util.TimSort
> println Class.forName('java.util.TimSort') // => class java.util.TimSort
> println new Object() instanceof TimSort // IllegalAccessError
> {code}
> Having said that is it really any different than being able to get the class
> via Class.forName?
> If the Java behavior is deemed correct, the fix would be to filter non-public
> classes during star import resolution in ResolveVisitor, producing a clean
> compile-time error instead of a runtime error. This is technically a breaking
> change but only affects code that was already failing at runtime on modular
> JDKs.
> This also benefits the import module feature (GROOVY-11896), which expands to
> star imports — filtering at the resolution level means module imports
> correctly include only public types, matching Java's import module semantics.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
