[
https://issues.apache.org/jira/browse/GROOVY-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134516#comment-18134516
]
ASF GitHub Bot commented on GROOVY-12555:
-----------------------------------------
jdaugherty commented on PR #3084:
URL: https://github.com/apache/groovy/pull/3084#issuecomment-6511397772
Thanks for the review.
**Compatibility.** Added to the PR description and to the JIRA. For a
compilation unit in the default package, a simple type name that is not
declared or imported in the unit and not in the same `CompilationUnit` is now
looked up on the class path, and on the source path of the `GroovyClassLoader`,
as a default-package class before the default imports. A default-package `List`
or `Node` on the class path therefore shadows `java.util.List` /
`groovy.util.Node` in default-package code, where the default import used to
win. That matches Java (JLS §6.4.1: a type declared in the same package, the
unnamed package included, shadows a type imported on demand), what Groovy
already does when the class is in the same `CompilationUnit`, and what
`resolveFromModule` already does for a named package via
`ConstructedClassWithPackage(module.getPackageName(), name)`. The named-package
path also means the extra lookup is nothing new: a named-package unit already
pays one cached class-path miss per JDK simple name (`foo.String`); a
default-package unit now pays the same.
**Side effects of `resolveToOuter`.** A miss leaves the `ClassNode`
untouched; `setRedirect` is only called on a hit. The only state change is that
`ClassNodeResolver.resolveName` caches the name as `NO_CLASS` in the resolver
shared by the `CompilationUnit`. The later `resolveToOuter(type)` in the chain
is only reached when the default imports also miss, and it then returns `null`
from the cache, so it is a no-op. On a hit the `||` chain short-circuits and
the later call never runs. The source-unit case (`Interrupt`, restart) is the
same path the later call would have taken, only earlier. I added a one-line
note to the Javadoc of `resolveFromDefaultPackage`, and moved the method above
the Javadoc of `resolveToOuter`, which the first version had separated from its
method. The backport branch has the same Javadoc.
> A default-package class resolves a precompiled default-package class to a
> default import of the same name
> ---------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12555
> URL: https://issues.apache.org/jira/browse/GROOVY-12555
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 4.0.33, 5.1.3
> Reporter: James Daugherty
> Priority: Major
>
> A class in the default package that refers to another class of the default
> package by its simple name finds that class while both are compiled together.
> When the other class is already compiled, the name resolves to a class of the
> default imports with the same simple name instead, here
> {{groovy.util.Factory}}, and the call fails at run time. In Java, a class of
> the same package, the unnamed one included, takes precedence over on-demand
> imports such as {{java.lang.*}}.
> {code:groovy}
> // Factory.groovy, default package
> class Factory {
> static String hello() { 'hello from the Factory of this project' }
> }
> // Caller.groovy, default package
> class Caller {
> static void main(String[] args) {
> println Factory.hello() // MissingMethodException for
> groovy.util.Factory when Factory is already compiled
> }
> }
> {code}
> Reproduced with 4.0.33, 5.1.3 and master. A reproducer with a groovyc script
> and an incremental Gradle build:
> https://github.com/jdaugherty/groovy-default-package-resolution
> *Cause*
> {{ResolveVisitor.resolve}} tries, in order, the classes of the module, of the
> compilation unit, of the default imports, and then the class path. For a
> module of a named package, the module step also looks up {{package.Name}} on
> the class path, so a compiled class of the same package comes first. For the
> default package there is no such step, so the default imports come before a
> compiled class of the default package.
> *Proposed fix*
> For a class of the default package, look up the simple name on the class path
> after the compilation unit and before the default imports, as is done for a
> named package.
> *Compatibility*
> For a compilation unit in the default package, a simple type name that is not
> declared or imported in the unit and not in the same {{CompilationUnit}} is
> now looked up on the class path, and on the source path of the
> {{GroovyClassLoader}}, as a default-package class before the default imports
> ({{java.lang}}, {{java.util}}, {{java.io}}, {{java.net}}, {{java.time}},
> {{groovy.lang}}, {{groovy.util}}, {{BigInteger}}, {{BigDecimal}}). A
> default-package {{List}} or {{Node}} on the class path therefore shadows
> {{java.util.List}} or {{groovy.util.Node}} in default-package code, where the
> default import used to win. This matches Java (JLS §6.4.1: a type declared in
> the same package, the unnamed package included, shadows a type imported on
> demand), what Groovy already does when the class is in the same
> {{CompilationUnit}}, and what {{ResolveVisitor.resolveFromModule}} does for a
> named package. The order only changes for an incremental or split build,
> which is the case where the old order produced different classes from a full
> build.
> Found while making incremental builds of a Grails application produce the
> same classes as a full build; see also GROOVY-12550 and GROOVY-12544.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
