[GitHub] [groovy] danielsun1106 commented on issue #998: GROOVY-9236: Avoid unnecessary resolving
danielsun1106 commented on issue #998: GROOVY-9236: Avoid unnecessary resolving URL: https://github.com/apache/groovy/pull/998#issuecomment-526793412 As we can see, STC is enabled by `@CompileStatic`. `groovy.lang.GroovyObject$groovy$transform$CompileStatic` is guessed by `resolveNestedClasses`, which has highest precedence of resolving. As for `Script1BeanInfo` and `Script1Customizer`, they will be looked up too before the changes of the PR... Frankly, I do not know where they come from for now... https://github.com/apache/groovy/blob/6e387d09b00663faccb8390a027e7e4d23a7a011/src/test/groovy/bugs/groovy9236/Groovy9236Bug.groovy#L64 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy] blackdrag commented on issue #998: GROOVY-9236: Avoid unnecessary resolving
blackdrag commented on issue #998: GROOVY-9236: Avoid unnecessary resolving URL: https://github.com/apache/groovy/pull/998#issuecomment-526744548 your change looks like progress no doubt, but why is there still "groovy.lang.GroovyObject$groovy$transform$CompileStatic" in there? ideally "import groovy.transform.CompileStatic" would cause a lookup to "groovy.transform.CompileStatic" and then it is done. And then what is Script1Customizer again for? And then the BeanInfo.. I think those two are specific to static compilation, right? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy] danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary resolving
danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary
resolving
URL: https://github.com/apache/groovy/pull/998#issuecomment-526739881
I tried to compile the following code to verify whether the times of
guessing class names are reduced. Then I got the result:
https://github.com/apache/groovy/pull/998#issuecomment-526408884
```groovy
import groovy.transform.CompileStatic
import java.util.stream.Collectors
import java.util.stream.Stream
@CompileStatic
void p() {
assert [2, 3, 4] == [1, 2, 3].stream().map(e -> e.plus
1).collect(Collectors.toList())
}
p()
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [groovy] danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary resolving
danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary
resolving
URL: https://github.com/apache/groovy/pull/998#issuecomment-526739881
I tried to compile the following code to verify whether the times of
guessing class names are reduced.
```groovy
import groovy.transform.CompileStatic
import java.util.stream.Collectors
import java.util.stream.Stream
@CompileStatic
void p() {
assert [2, 3, 4] == [1, 2, 3].stream().map(e -> e.plus
1).collect(Collectors.toList())
}
p()
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [groovy] danielsun1106 commented on issue #998: GROOVY-9236: Avoid unnecessary resolving
danielsun1106 commented on issue #998: GROOVY-9236: Avoid unnecessary resolving
URL: https://github.com/apache/groovy/pull/998#issuecomment-526739881
I tried to compile the following code to verify whether the times of
guessing class names are reduced.
```
import groovy.transform.CompileStatic
import java.util.stream.Collectors
import java.util.stream.Stream
@CompileStatic
void p() {
assert [2, 3, 4] == [1, 2, 3].stream().map(e -> e.plus
1).collect(Collectors.toList())
}
p()
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [groovy] blackdrag commented on issue #998: GROOVY-9236: Avoid unnecessary resolving
blackdrag commented on issue #998: GROOVY-9236: Avoid unnecessary resolving URL: https://github.com/apache/groovy/pull/998#issuecomment-526738578 could you first show what you compiled with that? And I think we will need more cases to for review. At the very least I would like to see the class that was resolved in the end. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy] eric-milles opened a new pull request #1001: GROOVY-9240: relax signature of RGM.traverse(File, Map, ...)
eric-milles opened a new pull request #1001: GROOVY-9240: relax signature of RGM.traverse(File, Map, ...) URL: https://github.com/apache/groovy/pull/1001 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919825#comment-16919825
]
Eric Milles commented on GROOVY-9236:
-
Thanks for attaching the discussion. If an issue ticket is created from a
discussion thread like that, the link in the initial description would help
dispel the guessing what the justification of the proposed change is.
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving adjusted, the above unnecessary resolving
> can be avoided.
> See the discussion in the dev mailing list:
> http://groovy.329449.n5.nabble.com/Performance-of-the-compiler-tt5750989.html
> and its attachment:
> http://groovy.329449.n5.nabble.com/attachment/5750989/0/CPU-hot-spots.txt
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (GROOVY-9242) Bump picocli to 4.0.3
[ https://issues.apache.org/jira/browse/GROOVY-9242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-9242. -- Resolution: Fixed > Bump picocli to 4.0.3 > - > > Key: GROOVY-9242 > URL: https://issues.apache.org/jira/browse/GROOVY-9242 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-beta-4 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [groovy] danielsun1106 merged pull request #1000: GROOVY-9242: Bump picocli to 4.0.3
danielsun1106 merged pull request #1000: GROOVY-9242: Bump picocli to 4.0.3 URL: https://github.com/apache/groovy/pull/1000 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9236:
---
Description:
{{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
{{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
class qualified name and load. In the process of resolving, lots of time wasted
on finding non-existing classes. So we should try to resolve classes in a
determined manner.
For example,
For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}} will
try to guess {{java.util.stream$Collectors}}, {{java.util$stream$Collectors}},
{{java$util$stream$Collectors}}.
And ② {{resolveFromDefaultImports}} will guess
{{java.lang.java$util$stream$Collectors}},
{{java.util.java$util$stream$Collectors}}, ...,
{{groovy.lang.java$util$stream$Collectors}}.
After the precedence of resolving adjusted, the above unnecessary resolving can
be avoided.
See the discussion in the dev mailing list:
http://groovy.329449.n5.nabble.com/Performance-of-the-compiler-tt5750989.html
and its attachment:
http://groovy.329449.n5.nabble.com/attachment/5750989/0/CPU-hot-spots.txt
was:
{{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
{{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
class qualified name and load. In the process of resolving, lots of time wasted
on finding non-existing classes. So we should try to resolve classes in a
determined manner.
For example,
For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}} will
try to guess {{java.util.stream$Collectors}}, {{java.util$stream$Collectors}},
{{java$util$stream$Collectors}}.
And ② {{resolveFromDefaultImports}} will guess
{{java.lang.java$util$stream$Collectors}},
{{java.util.java$util$stream$Collectors}}, ...,
{{groovy.lang.java$util$stream$Collectors}}.
After the precedence of resolving adjusted, the above unnecessary resolving can
be avoided.
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving adjusted, the above unnecessary resolving
> can be avoided.
> See the discussion in the dev mailing list:
> http://groovy.329449.n5.nabble.com/Performance-of-the-compiler-tt5750989.html
> and its attachment:
> http://groovy.329449.n5.nabble.com/attachment/5750989/0/CPU-hot-spots.txt
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919813#comment-16919813
]
Daniel Sun edited comment on GROOVY-9236 at 8/30/19 6:20 PM:
-
FYI. The PR tries to fix the issues discussed in the following thread, which
was started by [~melix]
[http://groovy.329449.n5.nabble.com/Performance-of-the-compiler-tt5750989.html]
In its attachment(CPU-hot-spots.txt), you will find some hot spots. The top one
is {{findClass}}.
http://groovy.329449.n5.nabble.com/attachment/5750989/0/CPU-hot-spots.txt
was (Author: daniel_sun):
FYI. The PR tries to fix the issues discussed in the following thread, which
was started by [~melix]
[http://groovy.329449.n5.nabble.com/Performance-of-the-compiler-tt5750989.html]
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving adjusted, the above unnecessary resolving
> can be avoided.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919813#comment-16919813
]
Daniel Sun commented on GROOVY-9236:
FYI. The PR tries to fix the issues discussed in the following thread, which
was started by [~melix]
[http://groovy.329449.n5.nabble.com/Performance-of-the-compiler-tt5750989.html]
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving adjusted, the above unnecessary resolving
> can be avoided.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919797#comment-16919797
]
Daniel Sun edited comment on GROOVY-9236 at 8/30/19 6:03 PM:
-
Here is the difference of classes to guess, the times to guess is reduced from
35 to 9(about 75% reduced) in the test case of the related PR:
* After changes(9 times to guess):
{code:java}
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$Collectors
Script1BeanInfo
Script1Customizer
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
{code}
* Before changes(35 times to guess):
{code:java}
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
Script1BeanInfo
Script1Customizer
groovy$transform$CompileStatic
groovy.lang.GroovyObject$Collectors
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.groovy$transform$CompileStatic
groovy.lang.java$util$stream$Collectors
groovy.lang.java$util$stream$Stream
groovy.transform$CompileStatic
groovy.util.groovy$transform$CompileStatic
groovy.util.java$util$stream$Collectors
groovy.util.java$util$stream$Stream
java$util$stream$Collectors
java$util$stream$Stream
java.io.groovy$transform$CompileStatic
java.io.java$util$stream$Collectors
java.io.java$util$stream$Stream
java.lang.groovy$transform$CompileStatic
java.lang.java$util$stream$Collectors
java.lang.java$util$stream$Stream
java.net.groovy$transform$CompileStatic
java.net.java$util$stream$Collectors
java.net.java$util$stream$Stream
java.util$stream$Collectors
java.util$stream$Stream
java.util.groovy$transform$CompileStatic
java.util.java$util$stream$Collectors
java.util.java$util$stream$Stream
java.util.stream$Collectors
java.util.stream$Stream
{code}
( [https://github.com/apache/groovy/pull/998#issuecomment-526408884] )
was (Author: daniel_sun):
Here is the difference of classes to guess, the times to guess is reduced from
35 to 9 in the test case of the related PR:
* After changes(9 times to guess):
{code:java}
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$Collectors
Script1BeanInfo
Script1Customizer
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
{code}
* Before changes(35 times to guess):
{code:java}
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
Script1BeanInfo
Script1Customizer
groovy$transform$CompileStatic
groovy.lang.GroovyObject$Collectors
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.groovy$transform$CompileStatic
groovy.lang.java$util$stream$Collectors
groovy.lang.java$util$stream$Stream
groovy.transform$CompileStatic
groovy.util.groovy$transform$CompileStatic
groovy.util.java$util$stream$Collectors
groovy.util.java$util$stream$Stream
java$util$stream$Collectors
java$util$stream$Stream
java.io.groovy$transform$CompileStatic
java.io.java$util$stream$Collectors
java.io.java$util$stream$Stream
java.lang.groovy$transform$CompileStatic
java.lang.java$util$stream$Collectors
java.lang.java$util$stream$Stream
java.net.groovy$transform$CompileStatic
java.net.java$util$stream$Collectors
java.net.java$util$stream$Stream
java.util$stream$Collectors
java.util$stream$Stream
java.util.groovy$transform$CompileStatic
java.util.java$util$stream$Collectors
java.util.java$util$stream$Stream
java.util.stream$Collectors
java.util.stream$Stream
{code}
( [https://github.com/apache/groovy/pull/998#issuecomment-526408884] )
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}},
[jira] [Comment Edited] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919801#comment-16919801
]
Daniel Sun edited comment on GROOVY-9236 at 8/30/19 6:02 PM:
-
In order to eliminate our worries, I added a test case to the PR to verify the
precedence is correct: {{testPrecedence}}
was (Author: daniel_sun):
In order to eliminate our worries, I add a test case to the PR to verify the
precedence is correct: {{testPrecedence}}
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving adjusted, the above unnecessary resolving
> can be avoided.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919801#comment-16919801
]
Daniel Sun commented on GROOVY-9236:
In order to eliminate our worries, I add a test case to the PR to verify the
precedence is correct: {{testPrecedence}}
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving adjusted, the above unnecessary resolving
> can be avoided.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919797#comment-16919797
]
Daniel Sun edited comment on GROOVY-9236 at 8/30/19 6:00 PM:
-
Here is the difference of classes to guess, the times to guess is reduced from
35 to 9 in the test case of the related PR:
* After changes(9 times to guess):
{code:java}
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$Collectors
Script1BeanInfo
Script1Customizer
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
{code}
* Before changes(35 times to guess):
{code:java}
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
Script1BeanInfo
Script1Customizer
groovy$transform$CompileStatic
groovy.lang.GroovyObject$Collectors
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.groovy$transform$CompileStatic
groovy.lang.java$util$stream$Collectors
groovy.lang.java$util$stream$Stream
groovy.transform$CompileStatic
groovy.util.groovy$transform$CompileStatic
groovy.util.java$util$stream$Collectors
groovy.util.java$util$stream$Stream
java$util$stream$Collectors
java$util$stream$Stream
java.io.groovy$transform$CompileStatic
java.io.java$util$stream$Collectors
java.io.java$util$stream$Stream
java.lang.groovy$transform$CompileStatic
java.lang.java$util$stream$Collectors
java.lang.java$util$stream$Stream
java.net.groovy$transform$CompileStatic
java.net.java$util$stream$Collectors
java.net.java$util$stream$Stream
java.util$stream$Collectors
java.util$stream$Stream
java.util.groovy$transform$CompileStatic
java.util.java$util$stream$Collectors
java.util.java$util$stream$Stream
java.util.stream$Collectors
java.util.stream$Stream
{code}
( [https://github.com/apache/groovy/pull/998#issuecomment-526408884] )
was (Author: daniel_sun):
Here is the difference of classes to guess:
* After changes(9 classes):
{code:java}
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$Collectors
Script1BeanInfo
Script1Customizer
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
{code}
* Before changes:
{code:java}
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
Script1BeanInfo
Script1Customizer
groovy$transform$CompileStatic
groovy.lang.GroovyObject$Collectors
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.groovy$transform$CompileStatic
groovy.lang.java$util$stream$Collectors
groovy.lang.java$util$stream$Stream
groovy.transform$CompileStatic
groovy.util.groovy$transform$CompileStatic
groovy.util.java$util$stream$Collectors
groovy.util.java$util$stream$Stream
java$util$stream$Collectors
java$util$stream$Stream
java.io.groovy$transform$CompileStatic
java.io.java$util$stream$Collectors
java.io.java$util$stream$Stream
java.lang.groovy$transform$CompileStatic
java.lang.java$util$stream$Collectors
java.lang.java$util$stream$Stream
java.net.groovy$transform$CompileStatic
java.net.java$util$stream$Collectors
java.net.java$util$stream$Stream
java.util$stream$Collectors
java.util$stream$Stream
java.util.groovy$transform$CompileStatic
java.util.java$util$stream$Collectors
java.util.java$util$stream$Stream
java.util.stream$Collectors
java.util.stream$Stream
{code}
( [https://github.com/apache/groovy/pull/998#issuecomment-526408884] )
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
>
[jira] [Commented] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919797#comment-16919797
]
Daniel Sun commented on GROOVY-9236:
Here is the difference of classes to guess:
* After changes:
{code:java}
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$Collectors
Script1BeanInfo
Script1Customizer
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
{code}
* Before changes:
{code:java}
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
Script1BeanInfo
Script1Customizer
groovy$transform$CompileStatic
groovy.lang.GroovyObject$Collectors
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.groovy$transform$CompileStatic
groovy.lang.java$util$stream$Collectors
groovy.lang.java$util$stream$Stream
groovy.transform$CompileStatic
groovy.util.groovy$transform$CompileStatic
groovy.util.java$util$stream$Collectors
groovy.util.java$util$stream$Stream
java$util$stream$Collectors
java$util$stream$Stream
java.io.groovy$transform$CompileStatic
java.io.java$util$stream$Collectors
java.io.java$util$stream$Stream
java.lang.groovy$transform$CompileStatic
java.lang.java$util$stream$Collectors
java.lang.java$util$stream$Stream
java.net.groovy$transform$CompileStatic
java.net.java$util$stream$Collectors
java.net.java$util$stream$Stream
java.util$stream$Collectors
java.util$stream$Stream
java.util.groovy$transform$CompileStatic
java.util.java$util$stream$Collectors
java.util.java$util$stream$Stream
java.util.stream$Collectors
java.util.stream$Stream
{code}
( [https://github.com/apache/groovy/pull/998#issuecomment-526408884] )
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving adjusted, the above unnecessary resolving
> can be avoided.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919797#comment-16919797
]
Daniel Sun edited comment on GROOVY-9236 at 8/30/19 5:57 PM:
-
Here is the difference of classes to guess:
* After changes(9 classes):
{code:java}
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$Collectors
Script1BeanInfo
Script1Customizer
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
{code}
* Before changes:
{code:java}
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
Script1BeanInfo
Script1Customizer
groovy$transform$CompileStatic
groovy.lang.GroovyObject$Collectors
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.groovy$transform$CompileStatic
groovy.lang.java$util$stream$Collectors
groovy.lang.java$util$stream$Stream
groovy.transform$CompileStatic
groovy.util.groovy$transform$CompileStatic
groovy.util.java$util$stream$Collectors
groovy.util.java$util$stream$Stream
java$util$stream$Collectors
java$util$stream$Stream
java.io.groovy$transform$CompileStatic
java.io.java$util$stream$Collectors
java.io.java$util$stream$Stream
java.lang.groovy$transform$CompileStatic
java.lang.java$util$stream$Collectors
java.lang.java$util$stream$Stream
java.net.groovy$transform$CompileStatic
java.net.java$util$stream$Collectors
java.net.java$util$stream$Stream
java.util$stream$Collectors
java.util$stream$Stream
java.util.groovy$transform$CompileStatic
java.util.java$util$stream$Collectors
java.util.java$util$stream$Stream
java.util.stream$Collectors
java.util.stream$Stream
{code}
( [https://github.com/apache/groovy/pull/998#issuecomment-526408884] )
was (Author: daniel_sun):
Here is the difference of classes to guess:
* After changes:
{code:java}
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$Collectors
Script1BeanInfo
Script1Customizer
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
{code}
* Before changes:
{code:java}
Script1$_p_lambda1BeanInfo
Script1$_p_lambda1Customizer
Script1BeanInfo
Script1Customizer
groovy$transform$CompileStatic
groovy.lang.GroovyObject$Collectors
groovy.lang.GroovyObject$CompileStatic
groovy.lang.GroovyObject$groovy$transform$CompileStatic
groovy.lang.GroovyObject$java$util$stream$Collectors
groovy.lang.GroovyObject$java$util$stream$Stream
groovy.lang.groovy$transform$CompileStatic
groovy.lang.java$util$stream$Collectors
groovy.lang.java$util$stream$Stream
groovy.transform$CompileStatic
groovy.util.groovy$transform$CompileStatic
groovy.util.java$util$stream$Collectors
groovy.util.java$util$stream$Stream
java$util$stream$Collectors
java$util$stream$Stream
java.io.groovy$transform$CompileStatic
java.io.java$util$stream$Collectors
java.io.java$util$stream$Stream
java.lang.groovy$transform$CompileStatic
java.lang.java$util$stream$Collectors
java.lang.java$util$stream$Stream
java.net.groovy$transform$CompileStatic
java.net.java$util$stream$Collectors
java.net.java$util$stream$Stream
java.util$stream$Collectors
java.util$stream$Stream
java.util.groovy$transform$CompileStatic
java.util.java$util$stream$Collectors
java.util.java$util$stream$Stream
java.util.stream$Collectors
java.util.stream$Stream
{code}
( [https://github.com/apache/groovy/pull/998#issuecomment-526408884] )
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving
[jira] [Commented] (GROOVY-9238) Groovy 2.5 AnnotationCollector not generating expected bytecode
[
https://issues.apache.org/jira/browse/GROOVY-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919778#comment-16919778
]
Andrew Allen commented on GROOVY-9238:
--
There are additional constructors that are expected to be available on classes
that use {{Immutable}} or {{Canonical}}. There is also the expectation that
the {{copyWith}} method should be available on {{Immutable}} classes that
enable that option in the annotation, however they are not present. Other
examples include changes to {{toString}}, {{equals}}, and {{hashCode}} which
should be updated as both {{Immutable}} and {{Canonical}} collect the
{{ToString}} and {{EqualsAndHashCode}} annotations
> Groovy 2.5 AnnotationCollector not generating expected bytecode
> ---
>
> Key: GROOVY-9238
> URL: https://issues.apache.org/jira/browse/GROOVY-9238
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, groovy-runtime
>Affects Versions: 2.5.x
> Environment: Ubuntu 18.04.3 LTS
>Reporter: Andrew Allen
>Priority: Major
>
> When using {{@AnnotationController}} with meta-annotations ( {{@Canonical}},
> {{@Immutable}} ) compiled classes do not contain the expected bytecode. As
> an example I have a [project | https://github.com/kod4n/groovy-gradle-issue]
> that is using a custom annotation with an annotation collector for
> {{@Immutatble}} and {{@CompileStatic}}. The error can be reproduced by
> running {{./gradlew clean test}} against the linked project.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (GROOVY-9089) STC: owner qualifier produces error for nested closures
[
https://issues.apache.org/jira/browse/GROOVY-9089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-9089.
-
Fix Version/s: 3.0.0-beta-1
2.5.7
Resolution: Fixed
This was resolved with changes linked to GROOVY-9063. Test case refactor for
proof was recently merged as well.
> STC: owner qualifier produces error for nested closures
> ---
>
> Key: GROOVY-9089
> URL: https://issues.apache.org/jira/browse/GROOVY-9089
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-4, 2.5.6
>Reporter: Eric Milles
>Priority: Major
> Fix For: 2.5.7, 3.0.0-beta-1
>
>
> In the example script below, the use of the "owner" qualifier causes an
> error. Replace with "delegate" and no error. Disable static compilation and
> no error.
> {code:groovy}
> class C1 {
> void m() {
> print 'outer delegate'
> }
> }
> class C2 {
> void m() {
> print 'inner delegate'
> }
> }
> void outer(@DelegatesTo(value = C1) Closure block) {
> block.delegate = new C1()
> block()
> }
> void inner(@DelegatesTo(value = C2, strategy = Closure.DELEGATE_FIRST)
> Closure block) {
> block.delegate = new C2()
> block()
> }
> @groovy.transform.CompileStatic // comment out and script prints "outer
> delegate" as expected
> void test() {
> outer {
> inner {
> owner.m() // "Cannot find matching method Script#m(). Please check if
> the declared type is right and if the method exists."
> // replace "owner" with "delegate" and CompileStatic has no error and
> prints "inner delegate" as expected
> }
> }
> }
> test()
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919766#comment-16919766
]
Eric Milles commented on GROOVY-9236:
-
Is there some measurement of the # of lookups reduced or time saved? The risk
of altering this area of the code seems very high, so I would expect the
benefit to also be high in order to justify the change.
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving adjusted, the above unnecessary resolving
> can be avoided.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919761#comment-16919761
]
Daniel Sun edited comment on GROOVY-9236 at 8/30/19 5:36 PM:
-
As you can find, {{resolveFromStaticInnerClasses}} will only resolve classes
whose name contains dots.
https://github.com/apache/groovy/blob/f22ad15939695a47522fdef4dd0aacef6ba667d2/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L563-L581
However {{resolveToOuter}} resolves types via
{{classNodeResolver.resolveName}}, which treats dots as sub-packages, i.e. it
will NOT resolve inner classes whose name contains dots.
https://github.com/apache/groovy/blob/f22ad15939695a47522fdef4dd0aacef6ba667d2/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L845
So no overlap in their target classes to resolve, thus no resolving precedence
will be changed.
was (Author: daniel_sun):
As you can find, {{resolveFromStaticInnerClasses}} will only resolve classes
whose name contains dots.
https://github.com/apache/groovy/blob/f22ad15939695a47522fdef4dd0aacef6ba667d2/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L563-L581
However {{resolveToOuter}} resolves types via
{{classNodeResolver.resolveName}}, which treats dots as sub-packages, i.e. it
will resolve inner classes whose name contains dots.
https://github.com/apache/groovy/blob/f22ad15939695a47522fdef4dd0aacef6ba667d2/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L845
So no overlap in their target classes to resolve, thus no resolving precedence
will be changed.
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving adjusted, the above unnecessary resolving
> can be avoided.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GROOVY-9236) Avoid unnecessary resolving
[
https://issues.apache.org/jira/browse/GROOVY-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919761#comment-16919761
]
Daniel Sun commented on GROOVY-9236:
As you can find, {{resolveFromStaticInnerClasses}} will only resolve classes
whose name contains dots.
https://github.com/apache/groovy/blob/f22ad15939695a47522fdef4dd0aacef6ba667d2/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L563-L581
However {{resolveToOuter}} resolves types via
{{classNodeResolver.resolveName}}, which treats dots as sub-packages, i.e. it
will resolve inner classes whose name contains dots.
https://github.com/apache/groovy/blob/f22ad15939695a47522fdef4dd0aacef6ba667d2/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L845
So no overlap in their target classes to resolve, thus no resolving precedence
will be changed.
> Avoid unnecessary resolving
> ---
>
> Key: GROOVY-9236
> URL: https://issues.apache.org/jira/browse/GROOVY-9236
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-beta-4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ResolveVisitor}}'s {{resolveFromStaticInnerClasses}},
> {{resolveFromDefaultImports}} and {{resolveNestedClass}} will try to guess
> class qualified name and load. In the process of resolving, lots of time
> wasted on finding non-existing classes. So we should try to resolve classes
> in a determined manner.
> For example,
> For {{java.util.stream.Collectors}}, ① {{resolveFromStaticInnerClasses}}
> will try to guess {{java.util.stream$Collectors}},
> {{java.util$stream$Collectors}}, {{java$util$stream$Collectors}}.
> And ② {{resolveFromDefaultImports}} will guess
> {{java.lang.java$util$stream$Collectors}},
> {{java.util.java$util$stream$Collectors}}, ...,
> {{groovy.lang.java$util$stream$Collectors}}.
> After the precedence of resolving adjusted, the above unnecessary resolving
> can be avoided.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GROOVY-9185) groovyc doesn't keep RetentionPolicy in generated bytecode
[
https://issues.apache.org/jira/browse/GROOVY-9185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919750#comment-16919750
]
Eric Milles commented on GROOVY-9185:
-
{{RetentionPolicy.SOURCE}} is the JVM default. Is the retention policy also
dropped for {{CLASS}} or {{RUNTIME}}?
> groovyc doesn't keep RetentionPolicy in generated bytecode
> --
>
> Key: GROOVY-9185
> URL: https://issues.apache.org/jira/browse/GROOVY-9185
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.7
>Reporter: zhb
>Priority: Major
>
>
> {code:java}
> $ groovyc -v
> Groovy compiler version 2.5.7
> Copyright 2003-2019 The Apache Software Foundation. http://groovy-lang.org/
> ---
> $ cat MyAnnotation.groovy
> import java.lang.annotation.Retention
> import java.lang.annotation.RetentionPolicy
> @Retention(RetentionPolicy.SOURCE)
> @interface MyAnnotation {}
> ---
> $ groovyc MyAnnotation.groovy && javap -private -v MyAnnotation
> Classfile /Users/zhb/Projects/tmp/groovy-anno/MyAnnotation.class
> Last modified 3 Jul 2019; size 146 bytes
> MD5 checksum 485f011b0c78ff7b08bd0e03b1b429cd
> Compiled from "MyAnnotation.groovy"
> public interface MyAnnotation extends java.lang.annotation.Annotation
> minor version: 0
> major version: 51
> flags: (0x2601) ACC_PUBLIC, ACC_INTERFACE, ACC_ABSTRACT, ACC_ANNOTATION
> this_class: #2 // MyAnnotation
> super_class: #4 // java/lang/Object
> interfaces: 1, fields: 0, methods: 0, attributes: 1
> Constant pool:
> #1 = Utf8 MyAnnotation
> #2 = Class #1 // MyAnnotation
> #3 = Utf8 java/lang/Object
> #4 = Class #3 // java/lang/Object
> #5 = Utf8 java/lang/annotation/Annotation
> #6 = Class #5 // java/lang/annotation/Annotation
> #7 = Utf8 MyAnnotation.groovy
> #8 = Utf8 SourceFile
> {
> }
> SourceFile: "MyAnnotation.groovy"
> ---
> $ cat MyJavaAnnotation.java
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> @Retention(RetentionPolicy.SOURCE)
> @interface MyJavaAnnotation {}
> ---
> $ javac MyJavaAnnotation.java && javap -private -v MyJavaAnnotation
> Classfile /Users/zhb/Projects/tmp/groovy-anno/MyJavaAnnotation.class
> Last modified 3 Jul 2019; size 292 bytes
> MD5 checksum c8ea8afe8f9fe148925db48177207f01
> Compiled from "MyJavaAnnotation.java"
> interface MyJavaAnnotation extends java.lang.annotation.Annotation
> minor version: 0
> major version: 55
> flags: (0x2600) ACC_INTERFACE, ACC_ABSTRACT, ACC_ANNOTATION
> this_class: #1 // MyJavaAnnotation
> super_class: #2 // java/lang/Object
> interfaces: 1, fields: 0, methods: 0, attributes: 2
> Constant pool:
> #1 = Class #11 // MyJavaAnnotation
> #2 = Class #12 // java/lang/Object
> #3 = Class #13 // java/lang/annotation/Annotation
> #4 = Utf8 SourceFile
> #5 = Utf8 MyJavaAnnotation.java
> #6 = Utf8 RuntimeVisibleAnnotations
> #7 = Utf8 Ljava/lang/annotation/Retention;
> #8 = Utf8 value
> #9 = Utf8 Ljava/lang/annotation/RetentionPolicy;
> #10 = Utf8 SOURCE
> #11 = Utf8 MyJavaAnnotation
> #12 = Utf8 java/lang/Object
> #13 = Utf8 java/lang/annotation/Annotation
> {
> }
> SourceFile: "MyJavaAnnotation.java"
> RuntimeVisibleAnnotations:
> 0: #7(#8=e#9.#10)
> java.lang.annotation.Retention(
> value=Ljava/lang/annotation/RetentionPolicy;.SOURCE
> )
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GROOVY-9237) GContracts and Groovy3
[
https://issues.apache.org/jira/browse/GROOVY-9237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919740#comment-16919740
]
Eric Milles commented on GROOVY-9237:
-
I have had to patch back the constructor and replace checks for "x ==
EmptyStatement.INSTANCE" with "x instanceof EmptyStatement" within Eclipse
tooling.
[https://github.com/groovy/groovy-eclipse/blob/master/base/org.codehaus.groovy30/src/org/codehaus/groovy/ast/expr/EmptyExpression.java#L45]
> GContracts and Groovy3
> --
>
> Key: GROOVY-9237
> URL: https://issues.apache.org/jira/browse/GROOVY-9237
> Project: Groovy
> Issue Type: Bug
>Reporter: Paul King
>Priority: Minor
>
> The following runs fine in 2.5.8 (needs gcontracts and asm jars on classpath):
> {code}
> import org.gcontracts.annotations.Invariant
> import groovy.transform.*
> @Invariant({ month >= 1 && month <= 12 && day >= 1 && day <= lastDay[month-1]
> })
> @MapConstructor
> @ToString(includeNames=true)
> class Calendar {
> private static final int[] lastDay = [31,29,31,30,31,30,31,31,30,31,30,31]
> int month
> int day
>
> def mutateByOneMonth() {
> month++
> }
> }
> new Calendar(month: 2, day: 2).mutateByOneMonth() // Okay
> new Calendar(month: 12, day: 2).mutateByOneMonth() // ClassInvariantViolation
> new Calendar(month: 1, day: 31).mutateByOneMonth() // ClassInvariantViolation
> {code}
> but with 3.0.0-beta-3 I get:
> {noformat}
> java.lang.IllegalAccessError: tried to access method
> org.codehaus.groovy.ast.stmt.EmptyStatement.()V from class
> org.gcontracts.generation.TryCatchBlockGenerator
> {noformat}
> We should check whether we have made an unneeded breaking change or whether a
> gcontracts upgrade might be needed.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GROOVY-9238) Groovy 2.5 AnnotationCollector not generating expected bytecode
[
https://issues.apache.org/jira/browse/GROOVY-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919739#comment-16919739
]
Eric Milles commented on GROOVY-9238:
-
What is the expectation that is missing from the bytecode?
> Groovy 2.5 AnnotationCollector not generating expected bytecode
> ---
>
> Key: GROOVY-9238
> URL: https://issues.apache.org/jira/browse/GROOVY-9238
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, groovy-runtime
>Affects Versions: 2.5.x
> Environment: Ubuntu 18.04.3 LTS
>Reporter: Andrew Allen
>Priority: Major
>
> When using {{@AnnotationController}} with meta-annotations ( {{@Canonical}},
> {{@Immutable}} ) compiled classes do not contain the expected bytecode. As
> an example I have a [project | https://github.com/kod4n/groovy-gradle-issue]
> that is using a custom annotation with an annotation collector for
> {{@Immutatble}} and {{@CompileStatic}}. The error can be reproduced by
> running {{./gradlew clean test}} against the linked project.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [groovy] danielsun1106 opened a new pull request #1000: GROOVY-9242: Bump picocli to 4.0.3
danielsun1106 opened a new pull request #1000: GROOVY-9242: Bump picocli to 4.0.3 URL: https://github.com/apache/groovy/pull/1000 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (GROOVY-9242) Bump picocli to 4.0.3
[ https://issues.apache.org/jira/browse/GROOVY-9242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun updated GROOVY-9242: --- Fix Version/s: 3.0.0-beta-4 > Bump picocli to 4.0.3 > - > > Key: GROOVY-9242 > URL: https://issues.apache.org/jira/browse/GROOVY-9242 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (GROOVY-9241) Bump gradle to 5.6.1
[ https://issues.apache.org/jira/browse/GROOVY-9241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-9241. -- Resolution: Fixed > Bump gradle to 5.6.1 > > > Key: GROOVY-9241 > URL: https://issues.apache.org/jira/browse/GROOVY-9241 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GROOVY-8329) Consider statically typed/compiled as default for Groovy 3.0
[ https://issues.apache.org/jira/browse/GROOVY-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919719#comment-16919719 ] Eric Milles commented on GROOVY-8329: - I think two very common use cases for Groovy are 1) automation/scripting of some kind and 2) unit testing (often with Spock). In these cases, the advantages of static compilation are not very great. My organization uses Groovy in main application code and we try to use static compilation most of the time in that scenario. I agree with [~daniel_sun] and others that the static compilation path(s) in the compiler are not as mature as the dymanic ones. You are likely to run into unexpected behavior if you use builder-style nested closures and some other structures that benefit greatly from dynamic behaviors. If you want to enable static compilation, my recommendation is to use a config script; you can get one from the link above or quite easily adapt that to limit its application to your app code or whatever. A one-time change to your build is far better than ensuring all developers apply @CompileStatic all the time or that a command-line argument or system property is made available but is completely inflexible. The argument for "invoke dynamic" is similar to this one. It could be the default, but you also currently have the flexibility of turning it on if you want it. Once you are able to supply a config script, you can then add things like @Canonical across the board using conventions in the codebase. > Consider statically typed/compiled as default for Groovy 3.0 > > > Key: GROOVY-8329 > URL: https://issues.apache.org/jira/browse/GROOVY-8329 > Project: Groovy > Issue Type: New Feature >Reporter: Endre Stølsvik >Priority: Major > > Personally, I do not understand why anyone would ever want to drop typing > from JVM based languages (or in any other language, for that matter). Thus, I > only started using Groovy "for real" when I discovered the @CompileStatic > annotation, which really made everything great! > If I could choose, I'd go for statically typed by default, with > @DynamicCompile or somesuch as an annotation I could turn on for methods that > uses the XML parsing features etc. > To me, it seems like more and more people are realizing that statically typed > languages is the way to go, notice e.g. TypeScript, Facebook's retrofitting > of types onto PHP with Hack, and even PHP's own typing in PHP 7. > Now with Kotlin joining the fray of JVM-based languages, whose literally > first two words on the wepage is "statically typed", getting special support > in Spring, and - notably - getting full support in Gradle, I'd say that this > applies more than ever. If Groovy "looses Gradle" to Kotlin due to the > ability to get a statically typed build script (oh, the joy!), I believe > Groovy will have a much harder time attracting new users. Turning Groovy into > one of the statically typed JVM languages, instead of hampering users with > "everything is an Object"-based runtime resolution, will increase the appeal > of the language. > The 3.0 can be a great point to change this. It could of course be reverted > back to previous logic by some -D switch (would need support in IDEs too, I > guess), or by sticking some magic "whole-sale annotation" at the top of the > source file, or something like this. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (GROOVY-9241) Bump gradle to 5.6.1
Daniel Sun created GROOVY-9241: -- Summary: Bump gradle to 5.6.1 Key: GROOVY-9241 URL: https://issues.apache.org/jira/browse/GROOVY-9241 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 3.0.0-beta-4 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (GROOVY-8329) Consider statically typed/compiled as default for Groovy 3.0
[
https://issues.apache.org/jira/browse/GROOVY-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919704#comment-16919704
]
Daniel Sun edited comment on GROOVY-8329 at 8/30/19 4:36 PM:
-
I do not think Groovy should enable STC by default because Groovy's main
advantage is its dynamic features. When we want better performance,
{{@CompileStatic}} will give us a hand, but it is just a bonus. Also, STC is
not mature enough as we can feel. Luckily, Groovy core team has been trying to
refine STC over time. Many fixes are very hard to be merged into 2_5_X from
master, so you will find STC support will be much better than before in Groovy
3.0.0. ( Our new committer [~emilles] contributes most of the STC fixes
recently. Really thanks to his hard work! )
BTW, if you want to enable STC by default in your projects, here is an article
for your reference:
[https://medium.com/@jonashavers/how-to-activate-type-checking-for-all-groovy-classes-57ce785d5028]
was (Author: daniel_sun):
I do not think Groovy should enable STC by default because Groovy's main
advantage is its dynamic features. When we want better performance,
{{@CompileStatic}} will give us a hand, but it is just a bonus. Also, STC is
not mature enough as we can feel. Luckily, Groovy core team has been trying to
refine STC over time. Many fixes are very hard to be merged into 2_5_X from
master, so you will find STC support will be much better than before in Groovy
3.0.0. ( Our new committer [~emilles] contributes most of the STC fixes
recently. Really thanks to his hard work! )
BTW, if you want to enable STC in your projects, here is an article for your
reference:
[https://medium.com/@jonashavers/how-to-activate-type-checking-for-all-groovy-classes-57ce785d5028]
> Consider statically typed/compiled as default for Groovy 3.0
>
>
> Key: GROOVY-8329
> URL: https://issues.apache.org/jira/browse/GROOVY-8329
> Project: Groovy
> Issue Type: New Feature
>Reporter: Endre Stølsvik
>Priority: Major
>
> Personally, I do not understand why anyone would ever want to drop typing
> from JVM based languages (or in any other language, for that matter). Thus, I
> only started using Groovy "for real" when I discovered the @CompileStatic
> annotation, which really made everything great!
> If I could choose, I'd go for statically typed by default, with
> @DynamicCompile or somesuch as an annotation I could turn on for methods that
> uses the XML parsing features etc.
> To me, it seems like more and more people are realizing that statically typed
> languages is the way to go, notice e.g. TypeScript, Facebook's retrofitting
> of types onto PHP with Hack, and even PHP's own typing in PHP 7.
> Now with Kotlin joining the fray of JVM-based languages, whose literally
> first two words on the wepage is "statically typed", getting special support
> in Spring, and - notably - getting full support in Gradle, I'd say that this
> applies more than ever. If Groovy "looses Gradle" to Kotlin due to the
> ability to get a statically typed build script (oh, the joy!), I believe
> Groovy will have a much harder time attracting new users. Turning Groovy into
> one of the statically typed JVM languages, instead of hampering users with
> "everything is an Object"-based runtime resolution, will increase the appeal
> of the language.
> The 3.0 can be a great point to change this. It could of course be reverted
> back to previous logic by some -D switch (would need support in IDEs too, I
> guess), or by sticking some magic "whole-sale annotation" at the top of the
> source file, or something like this.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GROOVY-8329) Consider statically typed/compiled as default for Groovy 3.0
[
https://issues.apache.org/jira/browse/GROOVY-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919704#comment-16919704
]
Daniel Sun commented on GROOVY-8329:
I do not think Groovy should enable STC by default because Groovy's main
advantage is its dynamic features. When we want better performance,
{{@CompileStatic}} will give us a hand, but it is just a bonus. Also, STC is
not mature enough as we can feel. Luckily, Groovy core team has been trying to
refine STC over time. Many fixes are very hard to be merged into 2_5_X from
master, so you will find STC support will be much better than before in Groovy
3.0.0. ( Our new committer [~emilles] contributes most of the STC fixes
recently. Really thanks to his hard work! )
BTW, if you want to enable STC in your projects, here is an article for your
reference:
[https://medium.com/@jonashavers/how-to-activate-type-checking-for-all-groovy-classes-57ce785d5028]
> Consider statically typed/compiled as default for Groovy 3.0
>
>
> Key: GROOVY-8329
> URL: https://issues.apache.org/jira/browse/GROOVY-8329
> Project: Groovy
> Issue Type: New Feature
>Reporter: Endre Stølsvik
>Priority: Major
>
> Personally, I do not understand why anyone would ever want to drop typing
> from JVM based languages (or in any other language, for that matter). Thus, I
> only started using Groovy "for real" when I discovered the @CompileStatic
> annotation, which really made everything great!
> If I could choose, I'd go for statically typed by default, with
> @DynamicCompile or somesuch as an annotation I could turn on for methods that
> uses the XML parsing features etc.
> To me, it seems like more and more people are realizing that statically typed
> languages is the way to go, notice e.g. TypeScript, Facebook's retrofitting
> of types onto PHP with Hack, and even PHP's own typing in PHP 7.
> Now with Kotlin joining the fray of JVM-based languages, whose literally
> first two words on the wepage is "statically typed", getting special support
> in Spring, and - notably - getting full support in Gradle, I'd say that this
> applies more than ever. If Groovy "looses Gradle" to Kotlin due to the
> ability to get a statically typed build script (oh, the joy!), I believe
> Groovy will have a much harder time attracting new users. Turning Groovy into
> one of the statically typed JVM languages, instead of hampering users with
> "everything is an Object"-based runtime resolution, will increase the appeal
> of the language.
> The 3.0 can be a great point to change this. It could of course be reverted
> back to previous logic by some -D switch (would need support in IDEs too, I
> guess), or by sticking some magic "whole-sale annotation" at the top of the
> source file, or something like this.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (GROOVY-9240) Better signature for ResourceGroovyMethods.traverse(File, Map, Closure) (and overloadings)
Mauro Molinari created GROOVY-9240:
--
Summary: Better signature for ResourceGroovyMethods.traverse(File,
Map, Closure) (and overloadings)
Key: GROOVY-9240
URL: https://issues.apache.org/jira/browse/GROOVY-9240
Project: Groovy
Issue Type: Improvement
Components: groovy-jdk
Affects Versions: 2.5.8
Reporter: Mauro Molinari
When you try to perform the following invocation in a statically
checked/compile Groovy class you'll get a compilation error:
{code:groovy}
myFolder.traverse([
type: FileType.FILES,
nameFilter: ~/.*\.(?i)pdf/
]) { println it }
{code}
The error is:
{noformat}
Groovy:[Static type checking] - Cannot call java.io.File#traverse(java.util.Map
, groovy.lang.Closure) with arguments
[java.util.LinkedHashMap ,
groovy.lang.Closure]
{noformat}
I think that more flexible and static type checker-friendly signatures for the
{{traverse}} methods would be:
{{ResourceGroovyMethods.traverse(File, Map, Closure)}}
{{ResourceGroovyMethods.traverse(File, Map)}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GROOVY-8329) Consider statically typed/compiled as default for Groovy 3.0
[
https://issues.apache.org/jira/browse/GROOVY-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919661#comment-16919661
]
Mauro Molinari commented on GROOVY-8329:
My 2 cents. I think Groovy will never go "static first", but I'm another one
who uses {{@CompileStatic}} on 90% of the classes, leaving the remaining 10%
with {{@CompileDynamic}}, either explicit or implicit, just because of Groovy
bugs in the static compiler.
Unfortunately, despite of many improvements, I still think the static compiler
is not mature enough yet, it breaks too often (and it's not always easy to
isolate test cases for reproducing). Also, some APIs are not optimised for
statically compiled code and using them as they were designed simply leads to a
compilation error.
So, I just wanted to say that I'm another one who uses Groovy for statically
compiled code only, therefore I second initiatives like GROOVY-8335 to provide
a simple mechanism "out-of-the-box" to throw in code to be statically compiled
by default. Using a config script I think it's a "too advanced" way to do
something that should be straight and immediately available.
> Consider statically typed/compiled as default for Groovy 3.0
>
>
> Key: GROOVY-8329
> URL: https://issues.apache.org/jira/browse/GROOVY-8329
> Project: Groovy
> Issue Type: New Feature
>Reporter: Endre Stølsvik
>Priority: Major
>
> Personally, I do not understand why anyone would ever want to drop typing
> from JVM based languages (or in any other language, for that matter). Thus, I
> only started using Groovy "for real" when I discovered the @CompileStatic
> annotation, which really made everything great!
> If I could choose, I'd go for statically typed by default, with
> @DynamicCompile or somesuch as an annotation I could turn on for methods that
> uses the XML parsing features etc.
> To me, it seems like more and more people are realizing that statically typed
> languages is the way to go, notice e.g. TypeScript, Facebook's retrofitting
> of types onto PHP with Hack, and even PHP's own typing in PHP 7.
> Now with Kotlin joining the fray of JVM-based languages, whose literally
> first two words on the wepage is "statically typed", getting special support
> in Spring, and - notably - getting full support in Gradle, I'd say that this
> applies more than ever. If Groovy "looses Gradle" to Kotlin due to the
> ability to get a statically typed build script (oh, the joy!), I believe
> Groovy will have a much harder time attracting new users. Turning Groovy into
> one of the statically typed JVM languages, instead of hampering users with
> "everything is an Object"-based runtime resolution, will increase the appeal
> of the language.
> The 3.0 can be a great point to change this. It could of course be reverted
> back to previous logic by some -D switch (would need support in IDEs too, I
> guess), or by sticking some magic "whole-sale annotation" at the top of the
> source file, or something like this.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [groovy] danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary resolving
danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary resolving URL: https://github.com/apache/groovy/pull/998#issuecomment-526538718 As `resolveFromStaticInnerClasses` only resolves classes whose name contains `.` and `resolveToOuter` only resolves classes whose name does not contains `.`, no overlap in their target classes to resolve, thus no breaking changes if we change the precedence of resolving IMO. (See the comment in the following code) https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L552 https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L845 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy] danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary resolving
danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary resolving URL: https://github.com/apache/groovy/pull/998#issuecomment-526538718 As `resolveFromStaticInnerClasses` only resolves classes whose name contains `.` and `resolveToOuter` only resolves classes whose name does not contains `.`, no overlap in their target classes to resolve, thus no breaking changes in the PR IMO. (See the comment in the following code) https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L845 https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L552 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy] danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary resolving
danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary resolving URL: https://github.com/apache/groovy/pull/998#issuecomment-526538718 As `resolveFromStaticInnerClasses` only resolves classes whose name contains `.` and `resolveToOuter` only resolves classes whose name does not contains `.`, no overlap in their target classes to resolve, thus no breaking changes in the PR IMO. (See the comment in the following code) https://github.com/apache/groovy/blob/79dfd8586b33e3c80add6b2ffb26c07ff7a6e8b3/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L552-L558 https://github.com/apache/groovy/blob/79dfd8586b33e3c80add6b2ffb26c07ff7a6e8b3/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L845-L856 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy] danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary resolving
danielsun1106 edited a comment on issue #998: GROOVY-9236: Avoid unnecessary resolving URL: https://github.com/apache/groovy/pull/998#issuecomment-526538718 As `resolveToOuter` only resolves classes whose name does not contains `.` and `resolveFromStaticInnerClasses` only resolves classes whose name contains `.`, no overlap in their target classes to resolve, thus no breaking changes in the PR IMO. https://github.com/apache/groovy/blob/79dfd8586b33e3c80add6b2ffb26c07ff7a6e8b3/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L552-L558 https://github.com/apache/groovy/blob/79dfd8586b33e3c80add6b2ffb26c07ff7a6e8b3/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L845-L856 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy] danielsun1106 commented on issue #998: GROOVY-9236: Avoid unnecessary resolving
danielsun1106 commented on issue #998: GROOVY-9236: Avoid unnecessary resolving URL: https://github.com/apache/groovy/pull/998#issuecomment-526538718 As `resolveToOuter` only resolves classes whose name does not contains `.` and `resolveFromStaticInnerClasses` only resolves classes whose name contains `.`, no overlap in their target classes to resolve, thus no breaking changes in the PR IMO. https://github.com/apache/groovy/blob/79dfd8586b33e3c80add6b2ffb26c07ff7a6e8b3/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L845-L856 https://github.com/apache/groovy/blob/79dfd8586b33e3c80add6b2ffb26c07ff7a6e8b3/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L552-L558 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy] danielsun1106 commented on issue #998: GROOVY-9236: Avoid unnecessary resolving
danielsun1106 commented on issue #998: GROOVY-9236: Avoid unnecessary resolving URL: https://github.com/apache/groovy/pull/998#issuecomment-526532434 @blackdrag Jochen, if you could set aside some time to review the PR too, that would be great :-) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
