[GitHub] [groovy] asfgit closed pull request #1311: GROOVY-7848: STC: retain generics of list or map elements
asfgit closed pull request #1311: URL: https://github.com/apache/groovy/pull/1311 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
[GitHub] [groovy] paulk-asert commented on pull request #1309: GROOVY-9637: Improve the performance of GString
paulk-asert commented on pull request #1309: URL: https://github.com/apache/groovy/pull/1309#issuecomment-66043 I still wonder whether some folks might make use of current GString mutability in scenarios like templating. I wonder whether just applying the optimisations when @CompileStatic is in play makes sense. In that scenario, we could leave GString and GStringImpl classes alone and have a GStringImplCS class. 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
[jira] [Comment Edited] (GROOVY-9618) Property reference resolves to field, not getter when property name is single upper-case letter
[
https://issues.apache.org/jira/browse/GROOVY-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160325#comment-17160325
]
Paul King edited comment on GROOVY-9618 at 7/18/20, 4:09 AM:
-
Proposed PR#1316 merged. Notes:
* Special handling is done for the upper and lowercase variants rather than
trying to represent both variants as meta bean properties, otherwise when
serialising or calling {{getProperties()}}, you get two copies of things.
* There is some special handling of an upper case "Class" field vs
{{getClass()}} (see GROOVY-1018) but other cases e.g. {{getMetaClass()}} aren't
covered. We might want to extend "Class" support to static imports/categories.
It is a breaking change in cases like "MetaClass" and "Properties" but you can
access the field using attribute notation in those cases. Lowercase properties
are unaffected.
was (Author: paulk):
Proposed PR#1316 merged. Notes:
* Special handling is done for the upper and lowercase variants rather than
trying to represent both variants as meta bean properties, otherwise when
serialising or calling {{getProperties()}}, you get two copies of things.
* There is some special handling of an upper case "Class" field vs
{{getClass()}} (see GROOVY-1018) but other cases e.g. {{getMetaClass()}} aren't
covered. We might want to extend "Class" support to static imports/categories.
It is a breaking change in cases like "MetaClass".
> Property reference resolves to field, not getter when property name is single
> upper-case letter
> ---
>
> Key: GROOVY-9618
> URL: https://issues.apache.org/jira/browse/GROOVY-9618
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.19, 3.0.4, 2.5.12
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Major
> Labels: breaking
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Consider the following:
> {code:groovy}
> class A {
> private static X = 1
> static getX() { 2 }
> static class B {
> }
> }
> class C extends A.B {
> void test() {
> print X
> }
> }
> new C().test()
> {code}
> Execution of this script prints "1" when "2" is expected. If static property
> name is changed to "XY" or "x" the resolution works as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9618) Property reference resolves to field, not getter when property name is single upper-case letter
[
https://issues.apache.org/jira/browse/GROOVY-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9618:
--
Labels: breaking (was: )
> Property reference resolves to field, not getter when property name is single
> upper-case letter
> ---
>
> Key: GROOVY-9618
> URL: https://issues.apache.org/jira/browse/GROOVY-9618
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.19, 3.0.4, 2.5.12
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Major
> Labels: breaking
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Consider the following:
> {code:groovy}
> class A {
> private static X = 1
> static getX() { 2 }
> static class B {
> }
> }
> class C extends A.B {
> void test() {
> print X
> }
> }
> new C().test()
> {code}
> Execution of this script prints "1" when "2" is expected. If static property
> name is changed to "XY" or "x" the resolution works as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9618) Property reference resolves to field, not getter when property name is single upper-case letter
[
https://issues.apache.org/jira/browse/GROOVY-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160325#comment-17160325
]
Paul King edited comment on GROOVY-9618 at 7/18/20, 4:00 AM:
-
Proposed PR#1316 merged. Notes:
* Special handling is done for the upper and lowercase variants rather than
trying to represent both variants as meta bean properties, otherwise when
serialising or calling {{getProperties()}}, you get two copies of things.
* There is some special handling of an upper case "Class" field vs
{{getClass()}} (see GROOVY-1018) but other cases e.g. {{getMetaClass()}} aren't
covered. We might want to extend "Class" support to static imports/categories.
It is a breaking change in cases like "MetaClass".
was (Author: paulk):
Proposed PR#1316 merged. Notes:
* Special handling is done for the upper and lowercase variants rather than
trying to represent both variants as meta bean properties, otherwise when
serialising or calling {{getProperties()}}, you get two copies of things.
* There is special handling of an upper case "Class" field vs {{getClass()}}
(see GROOVY-1018) but other cases e.g. {{getMetaClass()}} aren't covered.
> Property reference resolves to field, not getter when property name is single
> upper-case letter
> ---
>
> Key: GROOVY-9618
> URL: https://issues.apache.org/jira/browse/GROOVY-9618
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.19, 3.0.4, 2.5.12
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Consider the following:
> {code:groovy}
> class A {
> private static X = 1
> static getX() { 2 }
> static class B {
> }
> }
> class C extends A.B {
> void test() {
> print X
> }
> }
> new C().test()
> {code}
> Execution of this script prints "1" when "2" is expected. If static property
> name is changed to "XY" or "x" the resolution works as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9618) Property reference resolves to field, not getter when property name is single upper-case letter
[
https://issues.apache.org/jira/browse/GROOVY-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-9618.
---
Fix Version/s: 3.0.5
4.0.0-alpha-1
Assignee: Paul King (was: Eric Milles)
Resolution: Fixed
Proposed PR#1316 merged. Notes:
* Special handling is done for the upper and lowercase variants rather than
trying to represent both variants as meta bean properties, otherwise when
serialising or calling {{getProperties()}}, you get two copies of things.
* There is special handling of an upper case "Class" field vs {{getClass()}}
(see GROOVY-1018) but other cases e.g. {{getMetaClass()}} aren't covered.
> Property reference resolves to field, not getter when property name is single
> upper-case letter
> ---
>
> Key: GROOVY-9618
> URL: https://issues.apache.org/jira/browse/GROOVY-9618
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.19, 3.0.4, 2.5.12
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Consider the following:
> {code:groovy}
> class A {
> private static X = 1
> static getX() { 2 }
> static class B {
> }
> }
> class C extends A.B {
> void test() {
> print X
> }
> }
> new C().test()
> {code}
> Execution of this script prints "1" when "2" is expected. If static property
> name is changed to "XY" or "x" the resolution works as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9645) Inconsistencies in JavaBean naming for property access
[ https://issues.apache.org/jira/browse/GROOVY-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-9645. --- Fix Version/s: 3.0.5 4.0.0-alpha-1 Resolution: Fixed Proposed PR#1316 merged. > Inconsistencies in JavaBean naming for property access > -- > > Key: GROOVY-9645 > URL: https://issues.apache.org/jira/browse/GROOVY-9645 > Project: Groovy > Issue Type: Bug >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.0-alpha-1, 3.0.5 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [groovy] asfgit merged pull request #1316: GROOVY-9645: Inconsistencies in JavaBean naming for property access
asfgit merged pull request #1316: URL: https://github.com/apache/groovy/pull/1316 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
[jira] [Commented] (GROOVY-9472) Static import causes unresolved reference to become resolved
[
https://issues.apache.org/jira/browse/GROOVY-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160211#comment-17160211
]
Eric Milles commented on GROOVY-9472:
-
It is this block in {{ResolveVisitor}} that adds type resolution for static
imports:
{code:java}
// GROOVY-7812(#1): Static inner classes cannot be accessed from other
files when running by 'groovy' command
// if the type to resolve is an inner class and it is in an outer class
which is not resolved,
// we set the resolved type to a placeholder class node, i.e. a
ConstructedOuterNestedClass instance
// when resolving the outer class later, we set the resolved type of
ConstructedOuterNestedClass instance to the actual inner class node(SEE
GROOVY-7812(#2))
private boolean resolveToOuterNested(final ClassNode type) {
CompileUnit compileUnit = currentClass.getCompileUnit();
if (compileUnit == null) return false;
String typeName = type.getName();
BiConsumer
setRedirectListener = (s, c) -> type.setRedirect(s);
ModuleNode module = currentClass.getModule();
for (ImportNode importNode : module.getStaticImports().values()) {
String importFieldName = importNode.getFieldName();
String importAlias = importNode.getAlias();
if (!typeName.equals(importAlias)) continue;
ConstructedOuterNestedClassNode constructedOuterNestedClassNode =
tryToConstructOuterNestedClassNodeViaStaticImport(compileUnit, importNode,
importFieldName, setRedirectListener);
if (null != constructedOuterNestedClassNode) {
compileUnit.addClassNodeToResolve(constructedOuterNestedClassNode);
return true;
}
}
{code}
> Static import causes unresolved reference to become resolved
>
>
> Key: GROOVY-9472
> URL: https://issues.apache.org/jira/browse/GROOVY-9472
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static Type Checker
>Affects Versions: 2.5.10
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {code:groovy|title=com/foo/Person.groovy}
> package com.foo
> @groovy.transform.builder.Builder
> class Person {
> String name
> }
> {code}
> 1.
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> class Main {
> static void main(String[] args) {
> Person.PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Trying to use it without a static import yields {{unable to resolve class
> Person.PersonBuilder}}, which is another issue.
> 2. Let's add a static import
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> The code compiles, but fails with {{java.lang.NoClassDefFoundError:
> PersonBuilder}} when run.
> 3. Let's add {{@CompileStatic}}
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> import groovy.transform.CompileStatic
> @CompileStatic
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Compilation fails with:
> {{Cannot assign value of type com.foo.Person$PersonBuilder to variable of
> type PersonBuilder}} and {{Cannot find matching method PersonBuilder#build()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9472) Static import causes unresolved reference to become resolved
[
https://issues.apache.org/jira/browse/GROOVY-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160209#comment-17160209
]
Eric Milles commented on GROOVY-9472:
-
Is "import static a.B.C" supposed to work for type C nested within type B? Or
is it reserved for fields, methods and properties?
https://issues.apache.org/jira/browse/GROOVY-9471?focusedCommentId=17152320&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17152320
> Static import causes unresolved reference to become resolved
>
>
> Key: GROOVY-9472
> URL: https://issues.apache.org/jira/browse/GROOVY-9472
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static Type Checker
>Affects Versions: 2.5.10
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {code:groovy|title=com/foo/Person.groovy}
> package com.foo
> @groovy.transform.builder.Builder
> class Person {
> String name
> }
> {code}
> 1.
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> class Main {
> static void main(String[] args) {
> Person.PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Trying to use it without a static import yields {{unable to resolve class
> Person.PersonBuilder}}, which is another issue.
> 2. Let's add a static import
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> The code compiles, but fails with {{java.lang.NoClassDefFoundError:
> PersonBuilder}} when run.
> 3. Let's add {{@CompileStatic}}
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> import groovy.transform.CompileStatic
> @CompileStatic
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Compilation fails with:
> {{Cannot assign value of type com.foo.Person$PersonBuilder to variable of
> type PersonBuilder}} and {{Cannot find matching method PersonBuilder#build()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-8715) Cannot resolve array of inner class from type in same package (no import)
[
https://issues.apache.org/jira/browse/GROOVY-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8715:
Summary: Cannot resolve array of inner class from type in same package (no
import) (was: Cannot Resolve Arrays of Inner Class)
> Cannot resolve array of inner class from type in same package (no import)
> -
>
> Key: GROOVY-8715
> URL: https://issues.apache.org/jira/browse/GROOVY-8715
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-3, 2.5.0, 3.0.0, 3.0.1
>Reporter: Ian
>Assignee: Eric Milles
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Two files in the 'pkg' package:
> {code:java|title=MyClass.groovy}
> package pkg
> class HasClass { static class MyClass {} }
> {code}
>
> {code:java|title=HasClass.groovy}
> package pkg
> private static void foo(HasClass.MyClass... val) {}
> //pkg.HasClass.MyClass[] val // Also Fails
> //pkg.HasClass.MyClass val // Does not fail
> {code}
> Results in the following error:
>
> {code:java}
> /home/ianl/IdeaProjects/VariousGroovy/src/main/groovy/pkg/UsesClass.groovy:
> 3: unable to resolve class HasClass.MyClass[]
> @ line 3, column 25.
>private static void foo(HasClass.MyClass... val) {}
>^
> {code}
> This fails only for arrays, not single references. It does not occur if the
> files are in the default package.
> It is also possible to work around it with a static import:
>
> {code:java|title=HasClass.groovy}
> package pkg
> import static HasClass.MyClass // Now it doesn't fail
> private static void foo(MyClass... val) {}
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] eric-milles opened a new pull request #1317: GROOVY-8715: check array in ResolveVisitor.resolveToInner
eric-milles opened a new pull request #1317: URL: https://github.com/apache/groovy/pull/1317 `ResolveVisitor#resolveToOuterNested` probably has the same issue with array types. I just did not want to break it down to understand what kind of test case to create. https://issues.apache.org/jira/browse/GROOVY-8715 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
[jira] [Assigned] (GROOVY-8715) Cannot Resolve Arrays of Inner Class
[
https://issues.apache.org/jira/browse/GROOVY-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-8715:
---
Assignee: Eric Milles
> Cannot Resolve Arrays of Inner Class
>
>
> Key: GROOVY-8715
> URL: https://issues.apache.org/jira/browse/GROOVY-8715
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-3, 2.5.0, 3.0.0, 3.0.1
>Reporter: Ian
>Assignee: Eric Milles
>Priority: Major
>
> Two files in the 'pkg' package:
> {code:java|title=MyClass.groovy}
> package pkg
> class HasClass { static class MyClass {} }
> {code}
>
> {code:java|title=HasClass.groovy}
> package pkg
> private static void foo(HasClass.MyClass... val) {}
> //pkg.HasClass.MyClass[] val // Also Fails
> //pkg.HasClass.MyClass val // Does not fail
> {code}
> Results in the following error:
>
> {code:java}
> /home/ianl/IdeaProjects/VariousGroovy/src/main/groovy/pkg/UsesClass.groovy:
> 3: unable to resolve class HasClass.MyClass[]
> @ line 3, column 25.
>private static void foo(HasClass.MyClass... val) {}
>^
> {code}
> This fails only for arrays, not single references. It does not occur if the
> files are in the default package.
> It is also possible to work around it with a static import:
>
> {code:java|title=HasClass.groovy}
> package pkg
> import static HasClass.MyClass // Now it doesn't fail
> private static void foo(MyClass... val) {}
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9617) map.put(key,value) and map[key] = value differ is key is a GString
[
https://issues.apache.org/jira/browse/GROOVY-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160059#comment-17160059
]
Eric Milles commented on GROOVY-9617:
-
If you want the same behavior in the short term, you can cast the key to
Object. This will force selection of {{putAt(Map,Object,...)}}.
> map.put(key,value) and map[key] = value differ is key is a GString
> --
>
> Key: GROOVY-9617
> URL: https://issues.apache.org/jira/browse/GROOVY-9617
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.10
>Reporter: Laurent Martelli
>Priority: Minor
>
> The subscript operator of Map transform {{GString}} keys to {{String. }}But
> {{put()}} does not. This is incoherent.
>
> {code:java}
> class App {
> static void main(String[] args) {
> println("subscript works: "+subscriptWorks())
> println("put works: "+putWorks())
> }
> static def subscriptWorks() {
> def map = [:]
> def x = "toto"
> def key = "$x"
> map[key] = "value"
> return map.containsKey(key)
> }
> static def putWorks() {
> def map = [:]
> def x = "toto"
> def key = "$x"
> map.put(key,"value")
> return map.containsKey(key)
> }
> }
> {code}
> Outputs this :
> {code:java}
> subscript works: false
> subscript works: true
> {code}
> It would be better to either cast all key parameters of all methods from
> GString to String or none. The current behaviour is very confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9617) map.put(key,value) and map[key] = value differ is key is a GString
[
https://issues.apache.org/jira/browse/GROOVY-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160056#comment-17160056
]
Eric Milles commented on GROOVY-9617:
-
The subscript operation {{map[key]}} has 2 potential resolutions at runtime:
{code}
void putAt(Object self, String property, Object newValue)
V putAt(Map self, K key, V value)
{code}
When the parameter distance algorithm is applied, it is actually the
Object,String,Object method that is selected when your key is a GStringImpl.
This is implemented by {{groovy.lang.MetaClassImpl#doChooseMostSpecificParams}}.
> map.put(key,value) and map[key] = value differ is key is a GString
> --
>
> Key: GROOVY-9617
> URL: https://issues.apache.org/jira/browse/GROOVY-9617
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.10
>Reporter: Laurent Martelli
>Priority: Minor
>
> The subscript operator of Map transform {{GString}} keys to {{String. }}But
> {{put()}} does not. This is incoherent.
>
> {code:java}
> class App {
> static void main(String[] args) {
> println("subscript works: "+subscriptWorks())
> println("put works: "+putWorks())
> }
> static def subscriptWorks() {
> def map = [:]
> def x = "toto"
> def key = "$x"
> map[key] = "value"
> return map.containsKey(key)
> }
> static def putWorks() {
> def map = [:]
> def x = "toto"
> def key = "$x"
> map.put(key,"value")
> return map.containsKey(key)
> }
> }
> {code}
> Outputs this :
> {code:java}
> subscript works: false
> subscript works: true
> {code}
> It would be better to either cast all key parameters of all methods from
> GString to String or none. The current behaviour is very confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9618) Property reference resolves to field, not getter when property name is single upper-case letter
[
https://issues.apache.org/jira/browse/GROOVY-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159877#comment-17159877
]
Paul King commented on GROOVY-9618:
---
The second commit in [PR#1316|https://github.com/apache/groovy/pull/1316]
should fix this issue.
> Property reference resolves to field, not getter when property name is single
> upper-case letter
> ---
>
> Key: GROOVY-9618
> URL: https://issues.apache.org/jira/browse/GROOVY-9618
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.19, 3.0.4, 2.5.12
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Consider the following:
> {code:groovy}
> class A {
> private static X = 1
> static getX() { 2 }
> static class B {
> }
> }
> class C extends A.B {
> void test() {
> print X
> }
> }
> new C().test()
> {code}
> Execution of this script prints "1" when "2" is expected. If static property
> name is changed to "XY" or "x" the resolution works as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9646) Using Closure (Groovy Construction like []) triggers loading of all FileSystemProviders
Andrew Malyhin created GROOVY-9646:
--
Summary: Using Closure (Groovy Construction like []) triggers
loading of all FileSystemProviders
Key: GROOVY-9646
URL: https://issues.apache.org/jira/browse/GROOVY-9646
Project: Groovy
Issue Type: Bug
Affects Versions: 3.0.4
Reporter: Andrew Malyhin
After migration from Groovy 2.5.10 and jdk8 to Groovy 3.0.4 and jdk 11 we have
faced the issue: the first using of closure inits FileSystemProviders from
classpath which are not required:
There are two traces that show initializing of
org.apache.sshd.common.file.root.RootedFileSystemProvider just calling
{code:java}
at
logback.LogbackConfigurator.configureConsoleAppender(LogbackConfigurator.java:67)
at
logback.LogbackConfigurator.configureConsoleAppender(LogbackConfigurator.java:67)
at logback.LogbackConfigurator.configure(LogbackConfigurator.java:33) at
ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:156)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at
org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:55) at
org.slf4j.LoggerFactory.bind(LoggerFactory.java:150) at
org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124) at
org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:417) at
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:362) at
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388) at
org.apache.sshd.common.file.root.RootedFileSystemProvider.(RootedFileSystemProvider.java:70)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:779)
at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:721)
at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1394) at
java.base/java.nio.file.spi.FileSystemProvider.loadInstalledProviders(FileSystemProvider.java:155)
at
java.base/java.nio.file.spi.FileSystemProvider$1.run(FileSystemProvider.java:205)
at
java.base/java.nio.file.spi.FileSystemProvider$1.run(FileSystemProvider.java:202)
at java.base/java.security.AccessController.doPrivileged(Native Method) at
java.base/java.nio.file.spi.FileSystemProvider.installedProviders(FileSystemProvider.java:202)
at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:341) at
java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:293) at
org.codehaus.groovy.vmplugin.v9.ClassFinder.newFileSystem(ClassFinder.java:161)
at org.codehaus.groovy.vmplugin.v9.ClassFinder.find(ClassFinder.java:118) at
org.codehaus.groovy.vmplugin.v9.ClassFinder.find(ClassFinder.java:107) at
org.codehaus.groovy.vmplugin.v9.Java9.doFindClasses(Java9.java:106) at
org.codehaus.groovy.vmplugin.v9.Java9.getDefaultImportClasses(Java9.java:85) at
org.codehaus.groovy.control.ResolveVisitor.(ResolveVisitor.java:641) at
org.codehaus.groovy.runtime.InvokerHelper.(InvokerHelper.java:807) at
groovy.lang.GroovyObjectSupport.getDefaultMetaClass(GroovyObjectSupport.java:44)
at groovy.lang.GroovyObjectSupport.(GroovyObjectSupport.java:31) at
groovy.lang.Closure.(Closure.java:211) at
groovy.lang.Closure.(Closure.java:228) at
groovy.lang.Closure$1.(Closure.java:193) at
groovy.lang.Closure.(Closure.java:193){code}
and
{code:java}
at
logback.LogbackConfigurator.configureConsoleAppender(LogbackConfigurator.java:67)
at
logback.LogbackConfigurator.configureConsoleAppender(LogbackConfigurator.java:67)
at logback.LogbackConfigurator.configure(LogbackConfigurator.java:33) at
ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:156)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at
org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:55) at
org.slf4j.LoggerFactory.bind(LoggerFactory.java:150) at
org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124) at
org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:417) at
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:362) at
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388) at
org.apache.sshd.common.file.root.RootedFileSystemProvider.(RootedFileSystemProvider.java:70)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
a
[GitHub] [groovy] paulk-asert opened a new pull request #1316: GROOVY-9645: Inconsistencies in JavaBean naming for property access
paulk-asert opened a new pull request #1316: URL: https://github.com/apache/groovy/pull/1316 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
[jira] [Commented] (GROOVY-9618) Property reference resolves to field, not getter when property name is single upper-case letter
[
https://issues.apache.org/jira/browse/GROOVY-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159753#comment-17159753
]
Paul King commented on GROOVY-9618:
---
I created a separate issue to address the inconsistencies with normal property
access. We really need to resolve that before then looking at priorities
between properties and fields.
> Property reference resolves to field, not getter when property name is single
> upper-case letter
> ---
>
> Key: GROOVY-9618
> URL: https://issues.apache.org/jira/browse/GROOVY-9618
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.19, 3.0.4, 2.5.12
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Consider the following:
> {code:groovy}
> class A {
> private static X = 1
> static getX() { 2 }
> static class B {
> }
> }
> class C extends A.B {
> void test() {
> print X
> }
> }
> new C().test()
> {code}
> Execution of this script prints "1" when "2" is expected. If static property
> name is changed to "XY" or "x" the resolution works as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9645) Inconsistencies in JavaBean naming for property access
Paul King created GROOVY-9645: - Summary: Inconsistencies in JavaBean naming for property access Key: GROOVY-9645 URL: https://issues.apache.org/jira/browse/GROOVY-9645 Project: Groovy Issue Type: Bug Reporter: Paul King Assignee: Paul King -- This message was sent by Atlassian Jira (v8.3.4#803005)
