[
https://issues.apache.org/jira/browse/GROOVY-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134336#comment-18134336
]
ASF GitHub Bot commented on GROOVY-12555:
-----------------------------------------
jdaugherty opened a new pull request, #3084:
URL: https://github.com/apache/groovy/pull/3084
A class of the default package resolved a compiled class of the default
package only after the default imports, so it got java.util.* or
groovy.util.* classes of the same name, while a class of the default
package in the same compilation unit was found first. Look it up before
the default imports, as for a class of a named package.
`bugs.Groovy12555` compiles the classes once together and once with one of
them compiled against the others already compiled, as an incremental build
does, and compares the class files. It fails without the fix.
- Jira: [GROOVY-12555](https://issues.apache.org/jira/browse/GROOVY-12555)
- Reproducer, with `groovyc` and a Gradle incremental build:
https://github.com/jdaugherty/groovy-default-package-resolution
- Backport to `GROOVY_5_1_X`:
https://github.com/jdaugherty/groovy/commit/d84100ebe6ac81c73763af11ee9d5ec2dc5c3c15,
on the branch
[`GROOVY-12555-5_1_X`](https://github.com/jdaugherty/groovy/tree/GROOVY-12555-5_1_X).
It reproduces on 4.0.33, 5.1.3 and master. Could this be backported to 5.x
once it is merged?
> 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.
> 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)
