[jira] [Commented] (GROOVY-11337) Bump asciidoctorj-diagram to 2.3.0
[
https://issues.apache.org/jira/browse/GROOVY-11337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825403#comment-17825403
]
Jochen Theodorou commented on GROOVY-11337:
---
The arrows can maybe be prolonged with by using more arrow line elements.. ->
can be --> or ---> and plantuml is maybe displaying the in different lengths...
in the end it depends on the layout manager if it does respect that or not.
The original can maybe also fixed by installing graphviz/dot on the container
running the conversion. Something like
{code:java}
apk add --update --no-cache graphviz ttf-freefont
{code}
if it would be docker...
> Bump asciidoctorj-diagram to 2.3.0
> --
>
> Key: GROOVY-11337
> URL: https://issues.apache.org/jira/browse/GROOVY-11337
> Project: Groovy
> Issue Type: Dependency upgrade
>Reporter: Daniel Sun
>Assignee: Paul King
>Priority: Major
> Fix For: 5.0.0-alpha-8
>
> Attachments: image-2024-03-11-06-06-04-300.png,
> image-2024-03-11-06-07-12-504.png, image-2024-03-11-20-23-46-948.png
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11337) Bump asciidoctorj-diagram to 2.3.0
[ https://issues.apache.org/jira/browse/GROOVY-11337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825240#comment-17825240 ] Jochen Theodorou commented on GROOVY-11337: --- If you add "!pragma layout smetana" to the plantuml parts (top), then it should no longer use GraphViz. There is a GraphViz/dot in the plantuml jar, but only if the right one is used. > Bump asciidoctorj-diagram to 2.3.0 > -- > > Key: GROOVY-11337 > URL: https://issues.apache.org/jira/browse/GROOVY-11337 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Attachments: image-2024-03-11-06-06-04-300.png, > image-2024-03-11-06-07-12-504.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11311) Groovy Closure not retaining param annotations, but only for the default single object param case
[
https://issues.apache.org/jira/browse/GROOVY-11311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820629#comment-17820629
]
Jochen Theodorou commented on GROOVY-11311:
---
>From a dynamic Groovy only perspective the call methods are usually not even
>called for generated closures. Instead we call directly the doCall methods.
>The call methods are just helpers for calls made from Java. So I expect all
>important information to be on them.
>From a static Groovy perspective we know at compile time of course only the
>call methods call(), call(Object) and call(Object[]). They may do dynamic
>method calls to the real doCall methods. Of course this does not provide any
>type safety because for {int i ->i} we have a doCall(int) method, but also a
>call() method, which would fail if called. for {int i=1 ->i} we have of course
>two doCall methods doCall() and doCall(int), now call() is ok. call("foo") or
>call(1,2,3) is of course still not ok and will fail at runtime. We can
>overwrite the call methods to do direct method calls and safe the dynamic
>invocation, but I would still not add the annotation decorators there.
> Groovy Closure not retaining param annotations, but only for the default
> single object param case
> -
>
> Key: GROOVY-11311
> URL: https://issues.apache.org/jira/browse/GROOVY-11311
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8, 4.0.4
>Reporter: Val E
>Assignee: Eric Milles
>Priority: Minor
> Attachments: ClosureAnnotationsTest.groovy
>
>
> In trying to process Groovy closure param annotations, via Java reflection, I
> realized that there is one narrow case where the param annotations are not
> preserved in the generated call method.
> This happens only for the case of a single Object param type. All other
> variations retain the annotation, it can be a single param of a different
> type, or multiple params of Object type. I think this may have something to
> do with handling the default 'it' param
> ex:
> {code:java}
> {@TESTANNO def x-> } //wont retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO Object x-> } //wont retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO Integer x-> } //will retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO def x, @TESTANNO def y-> }//will retain @TESTANNO on both x and y
> {code}
>
> Attached a basic groovy script to demonstrate.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11313) Closure owner seems to be overwritten
[
https://issues.apache.org/jira/browse/GROOVY-11313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820513#comment-17820513
]
Jochen Theodorou commented on GROOVY-11313:
---
[~emilles] Looks like I forgot to make an example with owner comming from
another closure:
{code:Java}
def cl = { owner -> {return {owner}}}
assert cl(1)() == 1
{code}
The inner owner reference is not supposed to be resolved against the owner
getter of the outer closure, not even if owner comes from more outside, as long
as owner is a local variable. And of course I also expect this to work
(independent of the resolving strategy):
{code:Java}
def foo = 'bar'
def cl = { return {return {foo}}}
assert cl(1)() == foo
{code}
There should be no getter created for foo, since foo is a context variable
encapsulated in a holder, given to the closure at construction time. Therefore
I do not understand the change you did for this. But that is not your fault - I
see those getter actually exist for a longer time already. But really they
should not, exactly because of the name clash. There cannot be a getOwner
method for owner as property of the Closure and for owner as referenced local
variable. Either those getter are required, then this name clash is a problem
and your fix is probably a good temporary solution... or the getter are not
required, then we should not create them.
> Closure owner seems to be overwritten
> -
>
> Key: GROOVY-11313
> URL: https://issues.apache.org/jira/browse/GROOVY-11313
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.18
>Reporter: Tomás Crespo García
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.21, 4.0.19, 5.0.0-alpha-6
>
>
> I had a Groovy script with nested closures that used {{owner}} as the name of
> the outer closure's parameter (even though {{owner}} might conflict with the
> closure [owner|https://groovy-lang.org/closures.html#_owner_of_a_closure]):
> {code:java}
> import groovy.sql.GroovyRowResult
>
> runAll()
>
> void runAll() {
> List owners = [new GroovyRowResult([user_id: 1])]
> List pets = [new GroovyRowResult([id: 1])]
>
> owners.each { owner ->
> myMethod(1)
> pets.each { pet ->
> myMethod(2)
> println(owner.user_id)
> }
> }
> }
>
> void myMethod(int i) {
> println("Running my method ${i}")
> } {code}
> The same script worked as I expected in Groovy 3.x, but, in Groovy 4.0.18, it
> fails with the following error:
> {code:java}
> Exception in thread "main" groovy.lang.MissingPropertyException: No such
> property: myMethod for class: groovy.sql.GroovyRowResult
> at groovy.sql.GroovyRowResult.getProperty(GroovyRowResult.java:55)
> at groovy.sql.GroovyRowResult.get(GroovyRowResult.java:157)
> at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1389)
> at groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1335)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1088)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1007)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:645)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:628)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeOnDelegationObjects(ClosureMetaClass.java:391)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:328)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1007)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321)
> at Script1$_runAll_closure1$_closure2.doCall(Script1.groovy:16)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:328) {code}
> It seems that {{myMethod}} in the inner closure is trying to get resolved as
> a property of {{{}GroovyRowResult{}}}, which is the type of the {{owner}}
> parameter of the outer closure. The moment I rename {{owner}} to something
> else or transform the inner {{each}} to a {{for}} loop, the script works. It
> doesn't fail either if I don't try to access any property of {{owner}} inside
> the inner closure (such as {{{}owner.user_id{}}}).
>
> Is this expected?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11301) References to inaccesible methods with static compilation leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820103#comment-17820103
]
Jochen Theodorou commented on GROOVY-11301:
---
This can also be reproduced using the compilestatic annotation. I compared the
java generated output with what we create and found that there seems to be a
difference in what we give the lambda factory. In Java we have this helper
method:
{code:Java}
private static java.lang.String lambda$main$0();
descriptor: ()Ljava/lang/String;
flags: (0x100a) ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC
Code:
stack=1, locals=0, args_size=0
0: invokestatic #3 // Method
Test$A.m:()Ljava/lang/String;
3: areturn
LineNumberTable:
line 8: 0
{code} and a bootstrap method like this {code:Java}
#22 REF_invokeStatic
java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
Method arguments:
#23 ()Ljava/lang/Object;
#24 REF_invokeStatic Test.lambda$main$0:()Ljava/lang/String;
#25 ()Ljava/lang/String;
{code}
as can be seen, the method handle reference to the local helper method is given
to LambdaMetafactory.
What we do is:
{code:Java}
#45 REF_invokeStatic
java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
Method arguments:
#30 ()Ljava/lang/Object;
#37 REF_invokeStatic Test$A.m:()Ljava/lang/String;
#38 ()Ljava/lang/String;
{code}
which is trying to give a handle to Test.A#m() to the LambdaFactory. Since we
use the general public Lookup object access to there is forbidden. We need to
either use a lookup created from the class itself (not sure if Test is enough
or if Test.A is required) or the helper method.
> References to inaccesible methods with static compilation leads to runtime
> error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
> Attachments: Test$A.class, Test.class
>
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11301) References to inaccesible methods with static compilation leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819822#comment-17819822
]
Jochen Theodorou commented on GROOVY-11301:
---
Ok, thanks. I can reproduce the issue correctly now. I think the issue is that
we use the wrong lookup object or this. [~daniel_sun]?
> References to inaccesible methods with static compilation leads to runtime
> error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
> Attachments: Test$A.class, Test.class
>
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11313) Closure owner seems to be overwritten
[
https://issues.apache.org/jira/browse/GROOVY-11313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819818#comment-17819818
]
Jochen Theodorou commented on GROOVY-11313:
---
in { owner -> owner} owner refers to a local variable named owner, shadowing
the getOwner. local variables take precedence, because of lexical scope. If you
see a Closure as class then you expect the same rules to apply:
{code:Java}
class X {
def getFoo(){1}
def m(){foo}
def m2(foo){foo}
def m3(){
def foo = 42
return foo
}
}
assert new X().m() == 1
assert new X().m2("foo") == "foo"
assert new X().m3() == 42
{code}
Following these examples I see not why owner in a Closure should get resolved
to getOwner if there is a local variable of the same name.
{code:Java}
def owner = 1
def cl = {owner}
assert cl() == 1
def cl2 = {return {owner}}
assert cl2()() == 1
{code}
And frankly I even expect this:
{code:Java}
class X {
def owner = 22
def m() {return {owner}}
}
assert new X().m() == 22
{code}
But I am aware that this probably never worked. And changing it would break
things now. Out of delegate, owner and thisObject there is really only delegate
the one that can change and might not be available through other means. So from
inside a Closure we would really only to take care of that. But in the end the
MOP gets in the way for this last one. But the others are supposed to work.
> Closure owner seems to be overwritten
> -
>
> Key: GROOVY-11313
> URL: https://issues.apache.org/jira/browse/GROOVY-11313
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.18
>Reporter: Tomás Crespo García
>Priority: Major
>
> I had a Groovy script with nested closures that used {{owner}} as the name of
> the outer closure's parameter (even though {{owner}} might conflict with the
> closure [owner|https://groovy-lang.org/closures.html#_owner_of_a_closure]):
> {code:java}
> import groovy.sql.GroovyRowResult
>
> runAll()
>
> void runAll() {
> List owners = [new GroovyRowResult([user_id: 1])]
> List pets = [new GroovyRowResult([id: 1])]
>
> owners.each { owner ->
> myMethod(1)
> pets.each { pet ->
> myMethod(2)
> println(owner.user_id)
> }
> }
> }
>
> void myMethod(int i) {
> println("Running my method ${i}")
> } {code}
> The same script worked as I expected in Groovy 3.x, but, in Groovy 4.0.18, it
> fails with the following error:
> {code:java}
> Exception in thread "main" groovy.lang.MissingPropertyException: No such
> property: myMethod for class: groovy.sql.GroovyRowResult
> at groovy.sql.GroovyRowResult.getProperty(GroovyRowResult.java:55)
> at groovy.sql.GroovyRowResult.get(GroovyRowResult.java:157)
> at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1389)
> at groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1335)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1088)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1007)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:645)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:628)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeOnDelegationObjects(ClosureMetaClass.java:391)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:328)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1007)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321)
> at Script1$_runAll_closure1$_closure2.doCall(Script1.groovy:16)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:328) {code}
> It seems that {{myMethod}} in the inner closure is trying to get resolved as
> a property of {{{}GroovyRowResult{}}}, which is the type of the {{owner}}
> parameter of the outer closure. The moment I rename {{owner}} to something
> else or transform the inner {{each}} to a {{for}} loop, the script works. It
> doesn't fail either if I don't try to access any property of {{owner}} inside
> the inner closure (such as {{{}owner.user_id{}}}).
>
> Is this expected?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11301) References to inaccesible methods with static compilation leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818296#comment-17818296
]
Jochen Theodorou edited comment on GROOVY-11301 at 2/18/24 3:02 PM:
[~theosot] sorry for the delay... the problem is that the stack trace does not
show anything strange so far.. You are also not compiling as named module, but
even then they would be in the same module so module access should not matter.
I think there are currently only two things left. (1) try a newer/different JDK
version. (2) upload the class files so I can compare it with what I get locally.
was (Author: blackdrag):
[~theosot] sorry for the delay... the problem is that the stack trace does not
show anything strange so far.. You are also not compiling as named module, but
even then they would be in the same module so module access should not matter.
I think there are currently only two things left. (1) try a newer/different JDK
version. (2) upload the class file so I can compare it with what I get locally.
> References to inaccesible methods with static compilation leads to runtime
> error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11301) References to inaccesible methods with static compilation leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818296#comment-17818296
]
Jochen Theodorou commented on GROOVY-11301:
---
[~theosot] sorry for the delay... the problem is that the stack trace does not
show anything strange so far.. You are also not compiling as named module, but
even then they would be in the same module so module access should not matter.
I think there are currently only two things left. (1) try a newer/different JDK
version. (2) upload the class file so I can compare it with what I get locally.
> References to inaccesible methods with static compilation leads to runtime
> error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GROOVY-11312) Short notation for Boolean methods fails
[
https://issues.apache.org/jira/browse/GROOVY-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou closed GROOVY-11312.
-
Resolution: Won't Fix
This is an intentional change from GROOVY-10708 and related issues.
> Short notation for Boolean methods fails
>
>
> Key: GROOVY-11312
> URL: https://issues.apache.org/jira/browse/GROOVY-11312
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.18
>Reporter: Alan
>Assignee: Jochen Theodorou
>Priority: Major
>
> The following code succeeds
>
> {code:java}
> class Hello {
> public static boolean isBye() {
> return true
> }
> }
> Hello.bye {code}
>
> But the following fails
> {code:java}
> class Hello {
> public static Boolean isBye() {
> return true
> }
> }
> Hello.bye {code}
> with the exception
> {code:java}
> groovy.lang.MissingPropertyException: No such property: bye for class: Hello
> {code}
> Same is true when trying to access instance methods.
>
> Notice the only difference is the return type: Boolean vs boolean
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-11312) Short notation for Boolean methods fails
[
https://issues.apache.org/jira/browse/GROOVY-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou reassigned GROOVY-11312:
-
Assignee: Jochen Theodorou
> Short notation for Boolean methods fails
>
>
> Key: GROOVY-11312
> URL: https://issues.apache.org/jira/browse/GROOVY-11312
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.18
>Reporter: Alan
>Assignee: Jochen Theodorou
>Priority: Major
>
> The following code succeeds
>
> {code:java}
> class Hello {
> public static boolean isBye() {
> return true
> }
> }
> Hello.bye {code}
>
> But the following fails
> {code:java}
> class Hello {
> public static Boolean isBye() {
> return true
> }
> }
> Hello.bye {code}
> with the exception
> {code:java}
> groovy.lang.MissingPropertyException: No such property: bye for class: Hello
> {code}
> Same is true when trying to access instance methods.
>
> Notice the only difference is the return type: Boolean vs boolean
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11311) Groovy Closure not retaining param annotations, but only for the default single object param case
[
https://issues.apache.org/jira/browse/GROOVY-11311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817182#comment-17817182
]
Jochen Theodorou commented on GROOVY-11311:
---
I am a bit surprised because you check the call method. I was under the
impression we generate only a doCall method, which I am sure is happening...
yes, verified that.
Dow anyone remember why we decided to create call-methods additionally to the
doCall-methods?
> Groovy Closure not retaining param annotations, but only for the default
> single object param case
> -
>
> Key: GROOVY-11311
> URL: https://issues.apache.org/jira/browse/GROOVY-11311
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8, 4.0.4
>Reporter: Val E
>Priority: Major
> Attachments: ClosureAnnotationsTest.groovy
>
>
> In trying to process Groovy closure param annotations, via Java reflection, I
> realized that there is one narrow case where the param annotations are not
> preserved in the generated call method.
> This happens only for the case of a single Object param type. All other
> variations retain the annotation, it can be a single param of a different
> type, or multiple params of Object type. I think this may have something to
> do with handling the default 'it' param
> ex:
> {code:java}
> {@TESTANNO def x-> } //wont retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO Object x-> } //wont retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO Integer x-> } //will retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO def x, @TESTANNO def y-> }//will retain @TESTANNO on both x and y
> {code}
>
> Attached a basic groovy script to demonstrate.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11301) References to inaccesible methods leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812410#comment-17812410
]
Jochen Theodorou commented on GROOVY-11301:
---
[~theosot] for me it does not only compile, it does also execute without error.
Could you please provide the full stack trace and your Java version?
> References to inaccesible methods leads to runtime error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11301) References to inaccesible methods leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812393#comment-17812393
]
Jochen Theodorou edited comment on GROOVY-11301 at 1/30/24 4:16 PM:
Even though Test.A::m is a private method, A is an inner class of Test and
thus Test would have access to the method in Java. Also this does not fail in
groovy to any 3 or 4 version of Groovy. It also works for Groovy 5 alpha 1. If
it fails for master it must be something more recent
Trying out master with 191231a832efd2e2fc49391c01f8d176944d68e3 I can also not
reproduce the issue
was (Author: blackdrag):
Even though Test.A::m is a private method, A is an inner class of Test and
thus Test would have access to the method in Java. Also this does not fail in
groovy to any 3 or 4 version of Groovy. It also works for Groovy 5 alpha 1. If
it fails for master it must be something more recent
> References to inaccesible methods leads to runtime error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11301) References to inaccesible methods leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812393#comment-17812393
]
Jochen Theodorou commented on GROOVY-11301:
---
Even though Test.A::m is a private method, A is an inner class of Test and
thus Test would have access to the method in Java. Also this does not fail in
groovy to any 3 or 4 version of Groovy. It also works for Groovy 5 alpha 1. If
it fails for master it must be something more recent
> References to inaccesible methods leads to runtime error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11229) Support pattern matching and destructure
[ https://issues.apache.org/jira/browse/GROOVY-11229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806751#comment-17806751 ] Jochen Theodorou commented on GROOVY-11229: --- [~emilles][~daniel_sun] The de-structuring also give access to x and y? That is something still available through o or p of course, but the jep441 also targets further nesting. So yes, the Java16 version is a bit useless to us, the Java21 version though I see differently. Well... to be frank I find this feature massively overrated. And there is more coming of this in the future from Java... > Support pattern matching and destructure > > > Key: GROOVY-11229 > URL: https://issues.apache.org/jira/browse/GROOVY-11229 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Priority: Major > > See also: > [https://openjdk.org/jeps/394] > [https://openjdk.java.net/jeps/440] > [https://openjdk.org/jeps/441] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.
[ https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804416#comment-17804416 ] Jochen Theodorou commented on GROOVY-11271: --- [~emilles] See https://blog.mrhaki.com/2013/11/groovy-goodness-cache-methods.html. in case of for example @Memoized(maxCacheSize = 2) a LRU of size 2 is used. If now many threads read the memoized results and change the order of what is last recently used, this can result in the described problem. > ConcurrentCommonCache causes memory leaks. > -- > > Key: GROOVY-11271 > URL: https://issues.apache.org/jira/browse/GROOVY-11271 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.7 >Reporter: cong yang >Priority: Critical > > ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a > thread-safe data structure. However, CommonCache uses the underlying > LinkedHashMap, which causes conflicts when using the LRU algorithm because > the LinkedHashMap.get method modifies the internal linked list. This > conflicts with the read lock used by the get method in ConcurrentCommonCache > when multiple threads access it. Due to multithreading conflicts, the maximum > cache size of 64 becomes ineffective, ultimately causing memory leaks. > Additionally, we have already encountered memory leaks in our production > environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.
[ https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804244#comment-17804244 ] Jochen Theodorou commented on GROOVY-11271: --- [~daniel_sun] This is correct, but then it is not much better than a synchronized collection > ConcurrentCommonCache causes memory leaks. > -- > > Key: GROOVY-11271 > URL: https://issues.apache.org/jira/browse/GROOVY-11271 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.7 >Reporter: cong yang >Priority: Critical > > ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a > thread-safe data structure. However, CommonCache uses the underlying > LinkedHashMap, which causes conflicts when using the LRU algorithm because > the LinkedHashMap.get method modifies the internal linked list. This > conflicts with the read lock used by the get method in ConcurrentCommonCache > when multiple threads access it. Due to multithreading conflicts, the maximum > cache size of 64 becomes ineffective, ultimately causing memory leaks. > Additionally, we have already encountered memory leaks in our production > environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.
[ https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804198#comment-17804198 ] Jochen Theodorou commented on GROOVY-11271: --- to add ore details: https://github.com/apache/groovy/blob/5a3cf7c86feacc6f257cc72942e6ef8789920cf4/src/main/java/org/codehaus/groovy/runtime/memoize/CommonCache.java#L67 This creates a CommonCache where accessOrder is set to true and then any get call on the underlying LinkedHashMap can cause a write change, not covered appropriately by the checks. [~sunlan] This looks like a bigger change will be required to fix this > ConcurrentCommonCache causes memory leaks. > -- > > Key: GROOVY-11271 > URL: https://issues.apache.org/jira/browse/GROOVY-11271 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.7 >Reporter: cong yang >Priority: Critical > > ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a > thread-safe data structure. However, CommonCache uses the underlying > LinkedHashMap, which causes conflicts when using the LRU algorithm because > the LinkedHashMap.get method modifies the internal linked list. This > conflicts with the read lock used by the get method in ConcurrentCommonCache > when multiple threads access it. Due to multithreading conflicts, the maximum > cache size of 64 becomes ineffective, ultimately causing memory leaks. > Additionally, we have already encountered memory leaks in our production > environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11263) Analyze dead code
[
https://issues.apache.org/jira/browse/GROOVY-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801466#comment-17801466
]
Jochen Theodorou commented on GROOVY-11263:
---
[~daniel_sun] "It's better to avoid such dead code." I agree that it does not
make sense here and that in general you do not want to have that. But I do find
it quite nice to be able to just "return" when testing out things and not
having to comment out all the code
> Analyze dead code
> -
>
> Key: GROOVY-11263
> URL: https://issues.apache.org/jira/browse/GROOVY-11263
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
>
> Groovy allows dead code after {{return}}, e.g.
> {code:java}
> def m() {
>return
>def a = 1
> }
> {code}
> It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11230) ProxyGenerator creates a lot of AtomicReference instances regardless of "groovy.adapter.cache.default.size" setting
[ https://issues.apache.org/jira/browse/GROOVY-11230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787643#comment-17787643 ] Jochen Theodorou commented on GROOVY-11230: --- [~emilles] your change looks on first glance like you replace the LRUCache with a LinkedHashMap. I advice against this as LinkedHashMap is not thread safe and this scenario looks like it could have data races. > ProxyGenerator creates a lot of AtomicReference instances regardless of > "groovy.adapter.cache.default.size" setting > --- > > Key: GROOVY-11230 > URL: https://issues.apache.org/jira/browse/GROOVY-11230 > Project: Groovy > Issue Type: Improvement > Components: groovy-runtime >Reporter: Eric Milles >Assignee: Eric Milles >Priority: Major > > ProxyGenerator uses LRUCache which uses ConcurrentLinkedHashMap. This > creates a 2d array of AtomicReference that is sized based on number of > processor cores, not cache sizing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-8299) Generate bytecode for interface with default, private and static methods
[ https://issues.apache.org/jira/browse/GROOVY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786021#comment-17786021 ] Jochen Theodorou commented on GROOVY-8299: -- What is missing is "GROOVY-10060 Support static & private interface methods". As for the default methods itself, they are now the same as in Java. This includes Java using them from Groovy or reverse, Groovy/Java calling them defined in Java or Groovy and joint compilation. > Generate bytecode for interface with default, private and static methods > > > Key: GROOVY-8299 > URL: https://issues.apache.org/jira/browse/GROOVY-8299 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Daniel Sun >Assignee: Jochen Theodorou >Priority: Major > Labels: default-methods > Time Spent: 8h > Remaining Estimate: 0h > > Currently the interface with default methods is based on the traits, we > should provide real default methods introduced by Java8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GROOVY-11222) Cannot parse methods that return types starting with lowercase letters
[
https://issues.apache.org/jira/browse/GROOVY-11222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou closed GROOVY-11222.
-
Resolution: Won't Fix
We decided to make a breaking change in Groovy 4 here. Thus this is no bug and
expected. The GSL only talks about identifiers, not class names. I guess it
needs an update here. the reason for this change is that there are problems
with the name resolution leading to very long compilation times in which the
compiler basically looks for non-existing classes. This is because for example
"def foo = String" is valid in Groovy. It is not the only example causing
problems, just the most easy to understand. Using 3rd party libraries or
generated code in groovy, that is not following the conventions can be worked
around. Groovy supports import aliases. Thus you can do "import
com.generated.something.foo as Foo" and if you then do "def foo = Foo" it will
resolve to the class com.generated.something.foo. This alias can be used
anywhere, also in implements or extends.
> Cannot parse methods that return types starting with lowercase letters
> --
>
> Key: GROOVY-11222
> URL: https://issues.apache.org/jira/browse/GROOVY-11222
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 5.0.0-alpha-2, 4.0.15
>Reporter: Lyuben Atanasov
>Assignee: Jochen Theodorou
>Priority: Major
>
> According to the language specification, it is allowed to have class names
> that start with a lowercase letter:
> {quote}Identifiers start with a letter, a dollar or an underscore. They
> cannot start with a number.
> A letter can be in the following ranges:
> * 'a' to 'z' (lowercase ascii letter)
> * 'A' to 'Z' (uppercase ascii letter)
> * '\u00C0' to '\u00D6'
> * '\u00D8' to '\u00F6'
> * '\u00F8' to '\u00FF'
> * '\u0100' to '\uFFFE'{quote}
> This is the same as in Java.
> Defining types that start with lowercase letters works fine. As far as I can
> tell, I can also use such types as method arguments. What I cannot do, is to
> have methods that return types starting with lowercase letters.
> Here's a failing example:
> {code:groovy}
> public class person {
> private String firstName;
> private String lastName;
>
> person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public person createPerson(String firstName, String lastName) {
> return new person(firstName, lastName);
> }
>
> }
> {code}
> When parsing this code, it fails with the following error:
> {noformat}
> Script_b41cda4fe6804e170255542089871d79.groovy: 13: Unexpected input: '(' @
> line 13, column 31.
>public person createPerson(String firstName, String lastName) {
> ^
> 1 error
> {noformat}
> If I change the class name to start with a capital letter, everything works:
> {code:groovy}
> public class Person {
> private String firstName;
> private String lastName;
>
> Person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public Person createPerson(String firstName, String lastName) {
> return new Person(firstName, lastName);
> }
>
> }
> {code}
> So it looks like there is a discrepancy between the language specification
> and the grammar definition. I looked into the grammar and managed to extract
> the following relevant lines from it, which should make the issue evident:
> {code:java}
> methodDeclaration[int t, int ct]
> : modifiersOpt typeParameters? (returnType[$ct] nls)?
> methodName formalParameters
> (
> DEFAULT nls elementValue
> |
> (nls THROWS nls qualifiedClassNameList)?
> (nls methodBody)?
> )?
> ;
>
> returnType[int ct]
> :
> standardType
> | VOID
> ;
>
> standardType
> options { baseContext = type; }
> : annotationsOpt
> (
> primitiveType
> |
> standardClassOrInterfaceType
> )
> emptyDimsOpt
> ;
>
> standardClassOrInterfaceType
> options { baseContext = classOrInterfaceType; }
> : qualifiedStandardClassName typeArguments?
> ;
>
> qualifiedStandardClassName
> : qualifiedNameElements className (DOT className)*
> ;
>
> className
> : CapitalizedIdentifier
> ;
> {code}
> Here, it is allowed only to have a CapitalizedIdentifier as the class name.
> There is an obvious simple fix:
> {code:java}
> className
> : CapitalizedIdentifier | Identifier
> ;
> {code}
> This should make the
[jira] [Assigned] (GROOVY-11222) Cannot parse methods that return types starting with lowercase letters
[
https://issues.apache.org/jira/browse/GROOVY-11222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou reassigned GROOVY-11222:
-
Assignee: Jochen Theodorou
> Cannot parse methods that return types starting with lowercase letters
> --
>
> Key: GROOVY-11222
> URL: https://issues.apache.org/jira/browse/GROOVY-11222
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 5.0.0-alpha-2, 4.0.15
>Reporter: Lyuben Atanasov
>Assignee: Jochen Theodorou
>Priority: Major
>
> According to the language specification, it is allowed to have class names
> that start with a lowercase letter:
> {quote}Identifiers start with a letter, a dollar or an underscore. They
> cannot start with a number.
> A letter can be in the following ranges:
> * 'a' to 'z' (lowercase ascii letter)
> * 'A' to 'Z' (uppercase ascii letter)
> * '\u00C0' to '\u00D6'
> * '\u00D8' to '\u00F6'
> * '\u00F8' to '\u00FF'
> * '\u0100' to '\uFFFE'{quote}
> This is the same as in Java.
> Defining types that start with lowercase letters works fine. As far as I can
> tell, I can also use such types as method arguments. What I cannot do, is to
> have methods that return types starting with lowercase letters.
> Here's a failing example:
> {code:groovy}
> public class person {
> private String firstName;
> private String lastName;
>
> person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public person createPerson(String firstName, String lastName) {
> return new person(firstName, lastName);
> }
>
> }
> {code}
> When parsing this code, it fails with the following error:
> {noformat}
> Script_b41cda4fe6804e170255542089871d79.groovy: 13: Unexpected input: '(' @
> line 13, column 31.
>public person createPerson(String firstName, String lastName) {
> ^
> 1 error
> {noformat}
> If I change the class name to start with a capital letter, everything works:
> {code:groovy}
> public class Person {
> private String firstName;
> private String lastName;
>
> Person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public Person createPerson(String firstName, String lastName) {
> return new Person(firstName, lastName);
> }
>
> }
> {code}
> So it looks like there is a discrepancy between the language specification
> and the grammar definition. I looked into the grammar and managed to extract
> the following relevant lines from it, which should make the issue evident:
> {code:java}
> methodDeclaration[int t, int ct]
> : modifiersOpt typeParameters? (returnType[$ct] nls)?
> methodName formalParameters
> (
> DEFAULT nls elementValue
> |
> (nls THROWS nls qualifiedClassNameList)?
> (nls methodBody)?
> )?
> ;
>
> returnType[int ct]
> :
> standardType
> | VOID
> ;
>
> standardType
> options { baseContext = type; }
> : annotationsOpt
> (
> primitiveType
> |
> standardClassOrInterfaceType
> )
> emptyDimsOpt
> ;
>
> standardClassOrInterfaceType
> options { baseContext = classOrInterfaceType; }
> : qualifiedStandardClassName typeArguments?
> ;
>
> qualifiedStandardClassName
> : qualifiedNameElements className (DOT className)*
> ;
>
> className
> : CapitalizedIdentifier
> ;
> {code}
> Here, it is allowed only to have a CapitalizedIdentifier as the class name.
> There is an obvious simple fix:
> {code:java}
> className
> : CapitalizedIdentifier | Identifier
> ;
> {code}
> This should make the parser work in the same way as expected after reading
> the language spec. I am not sure, however, whether this won't break anything
> else.
> In order to avoid any unnecessary discussions about naming conventions: I am
> aware that by convention it is not OK to start a type name with anything
> other than a capital letter, but there are valid cases where it is desired to
> have such names (e.g. generated code based on external input, DSLs).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11204) Incorrect overload selection for subclasses
[
https://issues.apache.org/jira/browse/GROOVY-11204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781840#comment-17781840
]
Jochen Theodorou commented on GROOVY-11204:
---
I actually wonder if that was a good decision. I think the problem back then
was that if you have foo(C1) and foo(I1) where a class implements Interface I1
and extends C1, you normally want to have foo(I1). Java would give here a
method selection error. But In Groovy we are working with the runtime type, not
the compile time type, which makes a bit more difficult. Its probably not very
obvious with this explanation
> Incorrect overload selection for subclasses
> ---
>
> Key: GROOVY-11204
> URL: https://issues.apache.org/jira/browse/GROOVY-11204
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 4.0.12
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> I'm writing a Spring Security configurer and trying to add it to my
> configuration using {{apply(C)}}, but the Groovy compiler selects the wrong
> overload, and necessary initialization is not performed.
> {code:groovy}
> @Grab('org.springframework.security:spring-security-config:5.7.11')
> import
> org.springframework.security.config.annotation.authentication.builders.*
> import org.springframework.security.config.annotation.web.configurers.*
> import org.springframework.security.config.annotation.web.builders.*
> @Grab('org.springframework.security:spring-security-web:5.7.11')
> import org.springframework.security.web.*
> @Grab('javax.servlet:servlet-api:2.5')
> // AbstractHttpConfigurer extends SecurityConfigurerAdapter
> class MyConfigurer extends AbstractHttpConfigurer
> {}
> SecurityFilterChain securityFilterChain(HttpSecurity http) {
> http.apply(new MyConfigurer())
> // ^ should select apply(SecurityConfigurerAdapter), but selects
> apply(SecurityConfigurer)
> .and()
> .build()
> }
> securityFilterChain(new HttpSecurity({ }, new AuthenticationManagerBuilder({
> }), [:]))
> {code}
> This is probably a result of an edge case in the generics, since the bounds
> on the overloads are determined by type parameters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11208) No parse error for interface method with default value
[
https://issues.apache.org/jira/browse/GROOVY-11208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780603#comment-17780603
]
Jochen Theodorou commented on GROOVY-11208:
---
That syntax looks wrong. What bytecode is produced from that?
> No parse error for interface method with default value
> --
>
> Key: GROOVY-11208
> URL: https://issues.apache.org/jira/browse/GROOVY-11208
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Reporter: Eric Milles
>Priority: Major
>
> I noticed this syntax mentioned here:
> https://groovy.apache.org/wiki/GEP-12.html
> Is this supposed to be valid for some case or is it defunct?
> {code:groovy}
> interface I {
> def m() default { 1 }
> }
> {code}
> It does not produce any parser or compiler errors. But I don't think the
> default value saved in {{MethodNode}} is used for anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11193) Methods referenced by super cannot be found and are not executed
[
https://issues.apache.org/jira/browse/GROOVY-11193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778786#comment-17778786
]
Jochen Theodorou commented on GROOVY-11193:
---
[~emilles] I am not so much worried about having one version of Groovy for
compilation and another for test execution, I am worried about a library
compiled with Groovy 2 or 3 no longer working in Groovy 4. For smoothing this
over: How about a new method in ScriptBytecodeInterface like
invokeMethodOnSuperN2. I am not fully aware of what you changed. But when I
implemented the calls for default methods I noticed some "strange" (aka logic
that looks unfamiliar even though it should have been) code for the caller
class. My goal would actually be to replace the calls for super in Groovy 5
with invokedynamic.
> Methods referenced by super cannot be found and are not executed
>
>
> Key: GROOVY-11193
> URL: https://issues.apache.org/jira/browse/GROOVY-11193
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Marek Parfianowicz
>Assignee: Eric Milles
>Priority: Major
> Attachments: bug.zip
>
>
> When one method calls another method from a parent class via {{super}}
> keyword, the code is not executed at all.
> I tested this in version 4.0.0 and 4.0.14 - in both it fails. (x)
> It works correctly in 3.0.19. (/)
> It also fails in 2.5.23, but with a runtime exception -
> "{color:#172b4d}java.lang.AbstractMethodError" (x){color}
> Code to reproduce:
>
> {code:java}
> class MyClassBase {
> void setUp() {
> System.out.println("Called MyTestBase.setUp")
> }
> }{code}
>
> {code:java}
> class MyClass extends MyClassBase {
> void setUp() {
> super.setUp()
> System.out.println("Called MyTest.setUp")
> }
> static void main(String[] args) {
> System.out.println("About to create MyClass")
> MyClass my = new MyClass();
> my.setUp()
> }
> } {code}
> Output for Groovy 4.0.14:
> {noformat}
> [INFO] --- exec-maven-plugin:3.0.0:java (default) @ bug ---
> About to create MyClass
> [WARNING]
> groovy.lang.MissingMethodException: No signature of method:
> MyClassBase.setUp() is applicable for argument types: () values: []
> Possible solutions: setUp(), getAt(java.lang.String),
> tap(groovy.lang.Closure), sleep(long), sleep(long, groovy.lang.Closure),
> dump()
> at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap
> (ScriptBytecodeAdapter.java:72)
> at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN
> (ScriptBytecodeAdapter.java:148)
> at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0
> (ScriptBytecodeAdapter.java:166)
> at MyClass.setUp (MyClass.groovy:3)
> at MyClass$setUp.call (Unknown Source)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall
> (CallSiteArray.java:45)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
> (AbstractCallSite.java:125)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
> (AbstractCallSite.java:130)
> at MyClass.main (MyClass.groovy:10)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:254)
> at java.lang.Thread.run (Thread.java:750)
> {noformat}
> Please see the attached bug.zip sample project.
>
> Workaround:
> Use {{@CompileStatic}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11193) Methods referenced by super cannot be found and are not executed
[
https://issues.apache.org/jira/browse/GROOVY-11193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778163#comment-17778163
]
Jochen Theodorou commented on GROOVY-11193:
---
[~emilles]is that only for groovy-eclipse or also with normal Groovy? If this
is in general - did we mention this in breaking changes?
> Methods referenced by super cannot be found and are not executed
>
>
> Key: GROOVY-11193
> URL: https://issues.apache.org/jira/browse/GROOVY-11193
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Marek Parfianowicz
>Assignee: Eric Milles
>Priority: Major
> Attachments: bug.zip
>
>
> When one method calls another method from a parent class via {{super}}
> keyword, the code is not executed at all.
> I tested this in version 4.0.0 and 4.0.14 - in both it fails. (x)
> It works correctly in 3.0.19. (/)
> It also fails in 2.5.23, but with a runtime exception -
> "{color:#172b4d}java.lang.AbstractMethodError" (x){color}
> Code to reproduce:
>
> {code:java}
> class MyClassBase {
> void setUp() {
> System.out.println("Called MyTestBase.setUp")
> }
> }{code}
>
> {code:java}
> class MyClass extends MyClassBase {
> void setUp() {
> super.setUp()
> System.out.println("Called MyTest.setUp")
> }
> static void main(String[] args) {
> System.out.println("About to create MyClass")
> MyClass my = new MyClass();
> my.setUp()
> }
> } {code}
> Output for Groovy 4.0.14:
> {noformat}
> [INFO] --- exec-maven-plugin:3.0.0:java (default) @ bug ---
> About to create MyClass
> [WARNING]
> groovy.lang.MissingMethodException: No signature of method:
> MyClassBase.setUp() is applicable for argument types: () values: []
> Possible solutions: setUp(), getAt(java.lang.String),
> tap(groovy.lang.Closure), sleep(long), sleep(long, groovy.lang.Closure),
> dump()
> at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap
> (ScriptBytecodeAdapter.java:72)
> at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN
> (ScriptBytecodeAdapter.java:148)
> at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0
> (ScriptBytecodeAdapter.java:166)
> at MyClass.setUp (MyClass.groovy:3)
> at MyClass$setUp.call (Unknown Source)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall
> (CallSiteArray.java:45)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
> (AbstractCallSite.java:125)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
> (AbstractCallSite.java:130)
> at MyClass.main (MyClass.groovy:10)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:254)
> at java.lang.Thread.run (Thread.java:750)
> {noformat}
> Please see the attached bug.zip sample project.
>
> Workaround:
> Use {{@CompileStatic}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11194) groovyc missing features from the library compiler
[
https://issues.apache.org/jira/browse/GROOVY-11194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17775756#comment-17775756
]
Jochen Theodorou commented on GROOVY-11194:
---
Actually I think we are missing quite a bit documentation in that area.
--configscript can be used to pass a comma separated list of config scripts to
the compiler. Those are groovy scripts used to configure the compiler. Sigh...
I think one of the best references would be
https://blog.mrhaki.com/2016/01/groovy-goodness-customising-groovy.html We
really really miss doccumentation here! Anyway... the script is basically a
normal groovy script which has "configuration" as the current compiler
configuration object (see CompilerConfiguration) and you can set here the
values you are missing. There are additional helper methods like
withConfiguration to make some things a bit more easy, but I think you won't
need those.
Normally I would instead suggest to extend the command line interface to
support these options as has been done for GroovyMain. But then this would
maybe not be available for all the versions you intend to target. The config
script solution should work from Groovy 2.4.0+
> groovyc missing features from the library compiler
> --
>
> Key: GROOVY-11194
> URL: https://issues.apache.org/jira/browse/GROOVY-11194
> Project: Groovy
> Issue Type: New Feature
> Components: command line processing, Compiler
>Affects Versions: 3.0.19, 5.0.0-alpha-2, 4.0.15
>Reporter: Benjamin Marwell
>Priority: Critical
>
> Hello groovy team,
> no version of the groovy distribution supports any of those features on the
> {{groovyc}} command line, which are available when invoking the groovy
> compiler via library means:
> * setDebug( boolean )
> * setVerbose( boolean )
> * setWarningLevel( int )
> * setTolerance( int )
> * invokeDynamic via optimizationOptions.put("indy", true);
> optimizationOptions.put("int", false);
> * parallel Parsing via optimizationOptions.put("parallelParse", true);
> This is important when gplus-maven-plugin shall run in fork mode. Draft PR:
> https://github.com/groovy/GMavenPlus/pull/283
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11194) groovyc missing features from the library compiler
[
https://issues.apache.org/jira/browse/GROOVY-11194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17775594#comment-17775594
]
Jochen Theodorou commented on GROOVY-11194:
---
verbose is unused btw.
The only way to set this kind of options for the FilesystemCompiler right now
is using a config script.
> groovyc missing features from the library compiler
> --
>
> Key: GROOVY-11194
> URL: https://issues.apache.org/jira/browse/GROOVY-11194
> Project: Groovy
> Issue Type: New Feature
> Components: command line processing, Compiler
>Affects Versions: 3.0.19, 5.0.0-alpha-2, 4.0.15
>Reporter: Benjamin Marwell
>Priority: Critical
>
> Hello groovy team,
> no version of the groovy distribution supports any of those features on the
> {{groovyc}} command line, which are available when invoking the groovy
> compiler via library means:
> * setDebug( boolean )
> * setVerbose( boolean )
> * setWarningLevel( int )
> * setTolerance( int )
> * invokeDynamic via optimizationOptions.put("indy", true);
> optimizationOptions.put("int", false);
> * parallel Parsing via optimizationOptions.put("parallelParse", true);
> This is important when gplus-maven-plugin shall run in fork mode. Draft PR:
> https://github.com/groovy/GMavenPlus/pull/283
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-9801) Stub generator omits default interface methods
[
https://issues.apache.org/jira/browse/GROOVY-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-9801.
--
Fix Version/s: 5.0.0-alpha-2
Resolution: Fixed
> Stub generator omits default interface methods
> --
>
> Key: GROOVY-9801
> URL: https://issues.apache.org/jira/browse/GROOVY-9801
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 3.0.6
>Reporter: Christopher Smith
>Assignee: Jochen Theodorou
>Priority: Major
> Fix For: 5.0.0-alpha-2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When presented with a Groovy interface that has a default method (shiny and
> new!) the stub generator omits the "default" part, leading to compilation
> failures in Java classes due to unimplemented abstract methods.
> {code:groovy}
> interface HasDefaultMethod {
> default void method() { }
> }
> {code}
> {code:java}
> import java.lang.*;
> import java.util.*;
> import java.io.*;
> import java.net.*;
> import groovy.lang.*;
> import groovy.util.*;
> @groovy.transform.Trait() public interface HasDefaultMethod
> {
> ;
> void method();
> }
> {code}
> (The stray semicolon is also odd but doesn't appear to be pathological.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8859) traits allow access to private fields and static methods but not instance methods
[
https://issues.apache.org/jira/browse/GROOVY-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765031#comment-17765031
]
Jochen Theodorou commented on GROOVY-8859:
--
For me option 2 is good
> traits allow access to private fields and static methods but not instance
> methods
> -
>
> Key: GROOVY-8859
> URL: https://issues.apache.org/jira/browse/GROOVY-8859
> Project: Groovy
> Issue Type: Question
> Components: Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
> Labels: trait, traits
>
> It seems that private in a trait is akin to protected in a class. For
> example a class that implements a trait may access private fields (through
> namespace syntax) and properties and call private static methods. And it may
> use Type.super.method() to disambiguate methods if necessary. *Why, however,
> can a class that implements a trait not call private instance methods?* This
> is not really covered in the language specification.
> {code:groovy}
> trait T {
> private void privit() {
> println 'private'
> }
> public void publik() {
> println 'public'
> }
> }
> class C implements T {
> def m() {
> publik()
> privit()
> }
> }
> new C().m()
> {code}
> This fails with missing method. But if static modifier is added to privit,
> it succeeds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-9801) Stub generator omits default interface methods
[
https://issues.apache.org/jira/browse/GROOVY-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou reassigned GROOVY-9801:
Assignee: Jochen Theodorou
> Stub generator omits default interface methods
> --
>
> Key: GROOVY-9801
> URL: https://issues.apache.org/jira/browse/GROOVY-9801
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 3.0.6
>Reporter: Christopher Smith
>Assignee: Jochen Theodorou
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When presented with a Groovy interface that has a default method (shiny and
> new!) the stub generator omits the "default" part, leading to compilation
> failures in Java classes due to unimplemented abstract methods.
> {code:groovy}
> interface HasDefaultMethod {
> default void method() { }
> }
> {code}
> {code:java}
> import java.lang.*;
> import java.util.*;
> import java.io.*;
> import java.net.*;
> import groovy.lang.*;
> import groovy.util.*;
> @groovy.transform.Trait() public interface HasDefaultMethod
> {
> ;
> void method();
> }
> {code}
> (The stray semicolon is also odd but doesn't appear to be pathological.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-8299) Generate bytecode for interface with default, private and static methods
[ https://issues.apache.org/jira/browse/GROOVY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou reassigned GROOVY-8299: Assignee: Jochen Theodorou > Generate bytecode for interface with default, private and static methods > > > Key: GROOVY-8299 > URL: https://issues.apache.org/jira/browse/GROOVY-8299 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Daniel Sun >Assignee: Jochen Theodorou >Priority: Major > Labels: default-methods > > Currently the interface with default methods is based on the traits, we > should provide real default methods introduced by Java8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-10258) NPE: Pinpoint Exact Location in Call Chain
[
https://issues.apache.org/jira/browse/GROOVY-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758530#comment-17758530
]
Jochen Theodorou commented on GROOVY-10258:
---
>From my reading this is an internal solution where the JVM inspects bytecode
>to produce the message. And it looks like this cannot be influenced through
>Groovy. WE would have to spin our own solution and that would be expensive. If
>I am wrong anyone, please feel free to correct me on this. I too would like to
>have this, but currently it looks like having too much impact on performance.
> NPE: Pinpoint Exact Location in Call Chain
> --
>
> Key: GROOVY-10258
> URL: https://issues.apache.org/jira/browse/GROOVY-10258
> Project: Groovy
> Issue Type: Improvement
>Reporter: mgroovy
>Priority: Major
>
> Groovy should output the exact location where a NullPointerException occurred
> inside a call chain in the NPE message, if possible pretty printed.
> The JVM has been improved in this regard since OpenJDK 14:
> https://openjdk.java.net/jeps/358
> https://www.baeldung.com/java-14-nullpointerexception
> https://bugs.openjdk.java.net/browse/JDK-8233014
> The messages produced alas look pretty ugly for @CompileStatic Groovy (see
> below), due to its predominant use of properties instead of fields, and the
> original goal of JEP 358 to print the complete call chain (access path) seems
> to have been dropped, so it is not particularily helpful in some situations
> (see examples below).
> In Groovy 3.0.9 under OpenJDK 16:
> {code}
> @Newify(pattern=/[A-Z][A-Za-z0-9_]*/)
> //@CompileStatic
> class HelpfulNullPointerExceptionTest {
> static class X {
> X x; String s
> X(X x, String s = null) { this.x = x; this.s = s }
> @Override String toString() { "X($s,$x)" }
> }
> @Test
> void nullPointerInCallChain() {
> final x = X(X(X(X(null,"X-Men"
> println "x.x.x.x=$x.x.x.x"
> x.x.x = null
> /*
> * OpenJDK 16 (Eclipse jdk-16.0.2.7-hotspot) (Note:
> -XX:+ShowCodeDetailsInExceptionMessages is now always on by default)
> ** @CompileDynamic: java.lang.NullPointerException: Cannot get
> property 'x' on null object
> ** @CompileStatic: java.lang.NullPointerException: Cannot invoke
> "simple.groovy.HelpfulNullPointerExceptionTest$X.getX()" because the return
> value of "simple.groovy.HelpfulNullPointerExceptionTest$X.getX()" is null
> ** Would hope for something like (or its pretty-printed
> equivalent): java.lang.NullPointerException: Cannot get property 'x.x.x.x' on
> null object
> */
> println "x.x.x.x=$x.x.x.x"
> }
> @Canonical static class A { String a }
> @Canonical static class B { A a }
> @Canonical static class C { B b }
> @Canonical static class D { C c }
> @Test
> void nullPointerInCallChain2() {
> final x = D(C(B(A("aha!"
> println "x.c.b.a=$x.c.b.a"
> /*
> * OpenJDK 16 (Eclipse jdk-16.0.2.7-hotspot)
> ** @CompileDynamic: java.lang.NullPointerException: Cannot get
> property 'b' on null object
> ** @CompileStatic: java.lang.NullPointerException: Cannot invoke
> "simple.groovy.HelpfulNullPointerExceptionTest$C.getB()" because the return
> value of "simple.groovy.HelpfulNullPointerExceptionTest$D.getC()" is null
> ** Would hope for something like (or its pretty-printed
> equivalent): java.lang.NullPointerException: Cannot get property 'x.c.b.a' on
> null object
> */
> x.c = null
> println "x.c.b.a=$x.c.b.a"
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-4284) etablish a way to check for default meta class without creating it first
[ https://issues.apache.org/jira/browse/GROOVY-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-4284. -- Assignee: Jochen Theodorou Resolution: Fixed there is currently no use for that > etablish a way to check for default meta class without creating it first > > > Key: GROOVY-4284 > URL: https://issues.apache.org/jira/browse/GROOVY-4284 > Project: Groovy > Issue Type: Improvement > Components: groovy-runtime >Reporter: Jochen Theodorou >Assignee: Jochen Theodorou >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-10816) @NamedVariant does not work on methods on a trait or default methods on an interface
[
https://issues.apache.org/jira/browse/GROOVY-10816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-10816:
--
Labels: default-methods named-parameters (was: named-parameters)
> @NamedVariant does not work on methods on a trait or default methods on an
> interface
>
>
> Key: GROOVY-10816
> URL: https://issues.apache.org/jira/browse/GROOVY-10816
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.6
>Reporter: Robert Elliot
>Priority: Minor
> Labels: default-methods, named-parameters
>
> The following code fails to compile:
> {code:groovy}
> import groovy.transform.NamedVariant
> trait Foo {
> @NamedVariant
> def foo(String username = "sdf", String email = "ghj") {}
> }
> {code}
> with this error:
> {{Groovyc: Error during @NamedVariant processing. Class Foo$Trait$Helper
> already has a named-arg method of type
> [org.codehaus.groovy.ast.Parameter@15247533[name: namedArgs, type:
> java.util.Map, hasDefaultValue: false]]}}
> It works fine as a class.
> It fails as an interface with a default method.
> Perhaps this is intended, but if so I failed to find any documentation
> specifying that {{@NamedVariant}} only works with classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-8299) Generate bytecode for interface with default, private and static methods
[ https://issues.apache.org/jira/browse/GROOVY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou updated GROOVY-8299: - Labels: default-methods (was: ) > Generate bytecode for interface with default, private and static methods > > > Key: GROOVY-8299 > URL: https://issues.apache.org/jira/browse/GROOVY-8299 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Daniel Sun >Priority: Major > Labels: default-methods > > Currently the interface with default methods is based on the traits, we > should provide real default methods introduced by Java8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-3141) Ranges should be able to be used as Keys in Maps
[
https://issues.apache.org/jira/browse/GROOVY-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-3141.
--
Assignee: Jochen Theodorou
Resolution: Won't Fix
I think the use is too specific. If people still think this should be done I am
happy to reopen the issue
> Ranges should be able to be used as Keys in Maps
>
>
> Key: GROOVY-3141
> URL: https://issues.apache.org/jira/browse/GROOVY-3141
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Reporter: Matthew Corby-Eaglen
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Consider this:
> {code}
> def rangeMap = [(0..10) : "hello", (11..15) : "goodbye"]
> assertTrue(rangeMap.get(12) == "goodbye")
> {code}
> Currently you get null from the map, because 12 does not match the range as a
> key to the map.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-3032) GroovyScriptEngine needs SecurityPermissions
[ https://issues.apache.org/jira/browse/GROOVY-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-3032. -- Assignee: Jochen Theodorou Resolution: Won't Fix I am actually sorry to close this. But I think it makes no sense to implement this no that SecurityManager is phased out and no replacement is known. > GroovyScriptEngine needs SecurityPermissions > > > Key: GROOVY-3032 > URL: https://issues.apache.org/jira/browse/GROOVY-3032 > Project: Groovy > Issue Type: Improvement > Components: GroovyScriptEngine >Affects Versions: 1.5.6 > Environment: Any >Reporter: Matthew Corby-Eaglen >Assignee: Jochen Theodorou >Priority: Minor > Attachments: groovysecurity.diff > > > The GroovyScriptEngine requires some means of preventing certain objects from > running certain scripts. This would be useful for multi-user environments who > can log in and execute scripts via the shell. > An external wrapper would not work well because the GSE resolves scripts at > run time, and the URL of the scripts cannot be exposed before hand. > I suppose a change at the Script object level might be more appropriate, but > this would be effective. > Patch included. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-2734) Expose a method which allows the programmer to know that a script is out of date
[ https://issues.apache.org/jira/browse/GROOVY-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-2734. -- Assignee: Jochen Theodorou Resolution: Incomplete > Expose a method which allows the programmer to know that a script is out of > date > > > Key: GROOVY-2734 > URL: https://issues.apache.org/jira/browse/GROOVY-2734 > Project: Groovy > Issue Type: Improvement > Components: GroovyScriptEngine >Affects Versions: 1.5.4 >Reporter: Cédric Champeau >Assignee: Jochen Theodorou >Priority: Major > Attachments: gse-isoutofdate.patch > > > Following this thread : > http://www.nabble.com/GroovyScriptEngine-improvement---to16586229.html > Attached is a patch which exposes a new method, isCacheEntryOutOfDate(String > scriptName), which allows the developper to know whether a script will be > reloaded or not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-8536) StaticTypeCheckingSupport.ExtensionMethodCache is private
[ https://issues.apache.org/jira/browse/GROOVY-8536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-8536. -- Assignee: Jochen Theodorou Resolution: Fixed > StaticTypeCheckingSupport.ExtensionMethodCache is private > - > > Key: GROOVY-8536 > URL: https://issues.apache.org/jira/browse/GROOVY-8536 > Project: Groovy > Issue Type: Bug >Reporter: Jochen Theodorou >Assignee: Jochen Theodorou >Priority: Major > Labels: easyfix > > StaticTypeCheckingSupport exposes the protected constant > EXTENSION_METHOD_CACHE, but the type is ExtensionMethodCache, which is an > inner static and private class. For this constant to be useable it should not > be private and the cache class needs to be exposed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11161) Support extension methods inside the same compilation unit
[
https://issues.apache.org/jira/browse/GROOVY-11161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757646#comment-17757646
]
Jochen Theodorou commented on GROOVY-11161:
---
I changed to static compilation because non-static Groovy does not care about
extension methods until runtime. As for static compilation... there are
actually type checking extensions. That could be used if the list of methods is
known.
The other way would be of course that kind of annotation and then the type
checker (or a type checking extension) would have to search for these nodes and
use them... ah I think it is not fully the same if I think of overloads. there
might be already a fitting method, just an extension method would be maybe more
fitting. then methodMissing would not be done in the TypeCheckingExtension.
That means this would have to go even deeper. ..
As funny as it sounds it would probably the most easy to first compile without
static compilation and then again with, while using the precompiled extension
methods.
So far I found nothing of this very attractive.
> Support extension methods inside the same compilation unit
> --
>
> Key: GROOVY-11161
> URL: https://issues.apache.org/jira/browse/GROOVY-11161
> Project: Groovy
> Issue Type: Wish
> Components: Static compilation, Static Type Checker
>Affects Versions: 4.0.14
>Reporter: Christopher Smith
>Priority: Major
>
> Currently, the Groovy compiler supports extension methods only if they are
> previously compiled and provided to the current compilation run on the
> classpath. I have several projects where using extension methods to make
> project-specific micro-DSLs would substantially improve
> readability/maintainability, but because the extension methods need to refer
> to business objects, I would have to slice up the project into a pile of
> micro-projects.
> It would be very useful to be able to have a "bootstrap" mechanism to declare
> extension methods within the same project they're applied to, in the same way
> that annotations can be declared inside the same project. Either having an
> annotation {{@ProvidesExtensionMethods}} or providing a {{META-INF}} file
> (maybe being able to employ the usual mechanism for "forward extension
> declarations"?) would accomplish what I think I'm looking for.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11161) Support extension methods inside the same compilation unit
[
https://issues.apache.org/jira/browse/GROOVY-11161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-11161:
--
Component/s: Static compilation
Static Type Checker
(was: Compiler)
> Support extension methods inside the same compilation unit
> --
>
> Key: GROOVY-11161
> URL: https://issues.apache.org/jira/browse/GROOVY-11161
> Project: Groovy
> Issue Type: Wish
> Components: Static compilation, Static Type Checker
>Affects Versions: 4.0.14
>Reporter: Christopher Smith
>Priority: Major
>
> Currently, the Groovy compiler supports extension methods only if they are
> previously compiled and provided to the current compilation run on the
> classpath. I have several projects where using extension methods to make
> project-specific micro-DSLs would substantially improve
> readability/maintainability, but because the extension methods need to refer
> to business objects, I would have to slice up the project into a pile of
> micro-projects.
> It would be very useful to be able to have a "bootstrap" mechanism to declare
> extension methods within the same project they're applied to, in the same way
> that annotations can be declared inside the same project. Either having an
> annotation {{@ProvidesExtensionMethods}} or providing a {{META-INF}} file
> (maybe being able to employ the usual mechanism for "forward extension
> declarations"?) would accomplish what I think I'm looking for.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-7408) Reflection failed when the system time is before the last modified time of the groovy script
[ https://issues.apache.org/jira/browse/GROOVY-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-7408. -- Assignee: Jochen Theodorou Resolution: Incomplete I am closing this for now as incomplete. Anybody please feel to reopen this if needed. To really solve the issue I would require a minimal working example though > Reflection failed when the system time is before the last modified time of > the groovy script > > > Key: GROOVY-7408 > URL: https://issues.apache.org/jira/browse/GROOVY-7408 > Project: Groovy > Issue Type: Bug > Components: GroovyScriptEngine >Affects Versions: 1.8.3, 2.4.1 > Environment: redhat 6.0 >Reporter: Ethan Zhang >Assignee: Jochen Theodorou >Priority: Major > > Hi, > I use GroovyScriptEngine to run a groovy script from java program. Inside the > groovy script, I use Class.forName to load another groovy class. However, if > the operating system time is behind the groovy file last modified time, > following exception will be thrown: > java.lang.NoSuchMethodException: scripts.A.(scripts.A, > java.lang.String, java.lang.String, java.lang.String) > at java.lang.Class.getConstructor0(Unknown Source) > at java.lang.Class.getConstructor(Unknown Source) > at java_lang_Class$getConstructor$1.call(Unknown Source) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:110) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:122) > at scripts.B.create(B.groovy:41) > at scripts.B$create.call(Unknown Source) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:110) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:114) > at scripts.enrich.run(enrich.groovy:38) > at groovy.util.GroovyScriptEngine.run(GroovyScriptEngine.java:589) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-8660) Unexpected MethodSelectionException with implicit null argument
[
https://issues.apache.org/jira/browse/GROOVY-8660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-8660:
-
Affects Version/s: 4.0.13
> Unexpected MethodSelectionException with implicit null argument
> ---
>
> Key: GROOVY-8660
> URL: https://issues.apache.org/jira/browse/GROOVY-8660
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-2, 2.4.15, 2.5.0, 4.0.13
>Reporter: Daniil Ovchinnikov
>Priority: Major
> Labels: varargs
>
> {code:groovy}
> class OnlySingle {
> def foo(a) { "single param: $a" }
> }
> println new OnlySingle().foo()
> // as expected: 'single param: null'
> class OnlyVararg {
> def foo(a, ... b) { "vararg param: $a, $b" }
> }
> println new OnlyVararg().foo()
> // as expected: 'MME: No signature of method: OnlyVararg.foo() is applicable
> for argument types: () values: []'
> class Both {
> def foo(a) { "single param: $a" }
> def foo(a, ... b) { "vararg param: $a, $b" }
> }
> println new Both().foo()
> // unexpected:
> // MethodSelectionException: Could not find which method foo() to invoke from
> this list:
> // public java.lang.Object Both#foo(java.lang.Object)
> // public transient java.lang.Object Both#foo(java.lang.Object,
> [Ljava.lang.Object;)
> {code}
> If the exception is expected then {{OnlyVararg}} case should work too.
> If the exception is unexpected then {{Both#foo(Object)}} should be selected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-5116) Groovy enforces the use of the the dangerous permission java.util.PropertyPermission "*" "read,write" when using a SecurityManager
[
https://issues.apache.org/jira/browse/GROOVY-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-5116.
--
Assignee: Jochen Theodorou
Resolution: Won't Fix
I think it is fair to close this issue. GroovyMain is not a suitable entry
point for anything but the commandline groovy scripts.
> Groovy enforces the use of the the dangerous permission
> java.util.PropertyPermission "*" "read,write" when using a SecurityManager
> --
>
> Key: GROOVY-5116
> URL: https://issues.apache.org/jira/browse/GROOVY-5116
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 1.8.3
>Reporter: Benjamin Wolff
>Assignee: Jochen Theodorou
>Priority: Major
> Labels: contrib
>
> In several occurrences in the code, the system properties are accessed in
> this manner:
> groovy.grape.Grape.java
> {code}
> private static boolean enableGrapes =
> Boolean.valueOf(System.getProperties().getProperty("groovy.grape.enable",
> "true"));
> {code}
> The use of System.getProperties() forces the use of this permission in the
> SecurityManager: {noformat} java.util.PropertyPermission "*"
> "read,write"{noformat}
> This is not really desired in security sensitive environments. It is not
> possible to use more fine-grained permission declaration like e.g.:
> {noformat} java.util.PropertyPermission "groovy.*" "read,write"{noformat}
> This problem could be easily avoided by accessing the properties in this
> manner:
> {code}
> private static boolean enableGrapes =
> Boolean.valueOf(System.getProperty("groovy.grape.enable", "true"));
> {code}
> Without the use of System.getProperties() it is not mandatory to set the
> dangerous write permission on all system properties and more fine-grained
> security permissions like in the example could be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-9113) Unreachable code was not flagged by groovy compiler
[
https://issues.apache.org/jira/browse/GROOVY-9113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-9113:
-
Component/s: Compiler
Static compilation
Static Type Checker
(was: groovy-jdk)
> Unreachable code was not flagged by groovy compiler
> ---
>
> Key: GROOVY-9113
> URL: https://issues.apache.org/jira/browse/GROOVY-9113
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler, Static compilation, Static Type Checker
>Affects Versions: 2.4.6
> Environment: Groovy Version: 2.4.6 JVM: 1.8.0_91 Vendor: Oracle
> Corporation OS: Windows 10
>Reporter: Ashish
>Priority: Major
>
> The {{break}} statement after {{return'1'}} was not flagged as unreachable by
> groovy
> {code:java}
> switch(x) {
> case ['Front', 'Steer']:
> return '1'
> break
> case 'Drive':
> return '2'
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-9113) Unreachable code was not flagged by groovy compiler
[
https://issues.apache.org/jira/browse/GROOVY-9113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-9113:
-
Component/s: (was: Static compilation)
(was: Static Type Checker)
> Unreachable code was not flagged by groovy compiler
> ---
>
> Key: GROOVY-9113
> URL: https://issues.apache.org/jira/browse/GROOVY-9113
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 2.4.6
> Environment: Groovy Version: 2.4.6 JVM: 1.8.0_91 Vendor: Oracle
> Corporation OS: Windows 10
>Reporter: Ashish
>Priority: Major
>
> The {{break}} statement after {{return'1'}} was not flagged as unreachable by
> groovy
> {code:java}
> switch(x) {
> case ['Front', 'Steer']:
> return '1'
> break
> case 'Drive':
> return '2'
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-9113) Unreachable code was not flagged by groovy compiler
[
https://issues.apache.org/jira/browse/GROOVY-9113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-9113:
-
Issue Type: Improvement (was: Bug)
> Unreachable code was not flagged by groovy compiler
> ---
>
> Key: GROOVY-9113
> URL: https://issues.apache.org/jira/browse/GROOVY-9113
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-jdk
>Affects Versions: 2.4.6
> Environment: Groovy Version: 2.4.6 JVM: 1.8.0_91 Vendor: Oracle
> Corporation OS: Windows 10
>Reporter: Ashish
>Priority: Major
>
> The {{break}} statement after {{return'1'}} was not flagged as unreachable by
> groovy
> {code:java}
> switch(x) {
> case ['Front', 'Steer']:
> return '1'
> break
> case 'Drive':
> return '2'
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-6324) Cannot call closure like a method in type checked mode
[
https://issues.apache.org/jira/browse/GROOVY-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757489#comment-17757489
]
Jochen Theodorou commented on GROOVY-6324:
--
[~emilles] For a local variable we add information if we assign a closure to
it. Then we can use that information to determine if the call using that
variable is valid or not. But here it is a field, maybe even a precompiled
class in Java. There is no assignment we can trace. Where to get the meta
information we require? I think for this to compile a annotation like we use it
for DGM would be required. Not sure if the same annotation could be used or
should be used.
> Cannot call closure like a method in type checked mode
> --
>
> Key: GROOVY-6324
> URL: https://issues.apache.org/jira/browse/GROOVY-6324
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.2.0-beta-1, 2.3.0, 2.4.0-rc-1
>Reporter: Peter Niederwieser
>Priority: Major
>
> {{Closure closure = ...; closure()}} doesn't work in type-checked mode.
> Instead, one has to use {{closure.call()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-6519) removing direct usage of Binding from script
[ https://issues.apache.org/jira/browse/GROOVY-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757459#comment-17757459 ] Jochen Theodorou commented on GROOVY-6519: -- Actually this depends a bit on if we want to allow a script base class with different constructors than Script uses or not. If we do, then I am against this. If we don't then maybe > removing direct usage of Binding from script > > > Key: GROOVY-6519 > URL: https://issues.apache.org/jira/browse/GROOVY-6519 > Project: Groovy > Issue Type: Sub-task >Reporter: Jochen Theodorou >Priority: Major > > Instead of forcing Script to use Binding as a wrapper always, we can > introduce a loose connection by dynamic invocation then. This way it is > possible to use any object for the binding and it becomes more like a > delegate in Closure. The delegate has of course influence on the semantics > here. If a map is used, there won't be an exception in case an unused > variable is read in the script for example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-6228) Add asConcurrent(List/Map) method to Collections
[ https://issues.apache.org/jira/browse/GROOVY-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757449#comment-17757449 ] Jochen Theodorou commented on GROOVY-6228: -- [~paulk] DGM is more your area, what should we do here? > Add asConcurrent(List/Map) method to Collections > > > Key: GROOVY-6228 > URL: https://issues.apache.org/jira/browse/GROOVY-6228 > Project: Groovy > Issue Type: Improvement > Components: groovy-jdk >Reporter: Thierry De Leeuw >Priority: Minor > > Wouldn't it be better to replace/provide a new methods to get a > ConcurrentHashMap, instead of a collections.SynchronizedMap as it is a lot > more efficient? > If the "original" map is a TreeMap, of course, there is no equivalent in > Concurrent, so fallback to Synchronized seems a good compromise. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-6209) Weird error message with lower case class names
[
https://issues.apache.org/jira/browse/GROOVY-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-6209.
--
Assignee: Jochen Theodorou
Resolution: Won't Fix
The result of these discussions over the years turned into Groovy not trying to
resolve such cases at all. And since a workaround exists I close the issue
> Weird error message with lower case class names
> ---
>
> Key: GROOVY-6209
> URL: https://issues.apache.org/jira/browse/GROOVY-6209
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.1.5, 2.2.0-beta-1
>Reporter: Dr. Russel Winder
>Assignee: Jochen Theodorou
>Priority: Major
>
> The code:
> {code}
> class test {
> static void main(args) {
> test t = new test()
> }
> }
> {code}
> results in the error message:
> {noformat}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> /home/users/russel/tmp/BSkyB_2013-06-18/test.groovy: 3: Apparent variable 't'
> was found in a static scope but doesn't refer to a local variable, static
> field or class. Possible causes:
> You attempted to reference a variable in the binding or an instance variable
> from a static context.
> You misspelled a classname or statically imported field. Please check the
> spelling.
> You attempted to use a method 't' but left out brackets in a place not
> allowed by the grammar.
> @ line 3, column 10.
>test t = new test()
> ^
> 1 error
> {noformat}
> Editing the code g/test/s//Test/g means the code compiles and executes fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-5881) Type inference breaks in longer transitive generic structures
[
https://issues.apache.org/jira/browse/GROOVY-5881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-5881:
-
Affects Version/s: 4.0.13
> Type inference breaks in longer transitive generic structures
> -
>
> Key: GROOVY-5881
> URL: https://issues.apache.org/jira/browse/GROOVY-5881
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.0.6, 2.3.0, 2.4.0-beta-3, 4.0.13
>Reporter: Dimitar Dimitrov
>Priority: Major
>
> {code}
> class Test {
> @CompileStatic
> void printProgress(Map> markers, int i) {
> for (e in markers.entrySet()) {
> if (i%e.key==0) { print e.value(i) ; break }
> }
> }
> }
> {code}
> Fails to compile with: {{Groovyc: [Static type checking] - Cannot find
> matching method java.util.Map$Entry#value(int). Please check if the declared
> type is right and if the method exists.}}
> The following fixes the problem, though it should not be necesarry to do
> explicit 'call'.
> {code}
> class Test {
> @CompileStatic
> void printProgress(Map> markers, int i) {
> for (e in markers.entrySet()) {
> print e.value.call(i)
> }
> }
> }
> {code}
> For comparison, the following passes:
> {code}
> class Test {
> @CompileStatic
> void printProgress(Set> markers, int i) {
> for (e in markers) {
> print e(i)
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-5727) Ovverriding 3rd Party libraries shipped
[ https://issues.apache.org/jira/browse/GROOVY-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-5727. -- Fix Version/s: 2.5.0 Assignee: Jochen Theodorou Resolution: Fixed This seems to be fixed since at least 2.5.0, probably earlier > Ovverriding 3rd Party libraries shipped > --- > > Key: GROOVY-5727 > URL: https://issues.apache.org/jira/browse/GROOVY-5727 > Project: Groovy > Issue Type: Improvement > Components: Groovysh >Affects Versions: 2.0.4 >Reporter: deas >Assignee: Jochen Theodorou >Priority: Major > Labels: contrib > Fix For: 2.5.0 > > > Groovy 2.0.4 ships various 3rd party libraries, e.g. servlet-api-2.4.jar and > jsp-api-2.0.jar. These can get in the way and I see no reasonable way to use > user defined versions in groovysh. Of course you can introduce a custom > classloader searching locally before delegating to the parent or just remove > the library shipped to get it out of the way, but I feel there should be a > groovier way. Maybe you should just omit shipping these libraries. > A concrete situation where I encountered this problem was when I wanted a > groovy script to launch jetty with servlet 3.0 support, pulling in various > dependencies with Grape. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-5502) If/else branch does not always infer the variable type
[
https://issues.apache.org/jira/browse/GROOVY-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-5502:
-
Affects Version/s: 3.0.19
4.0.14
2.5.23
2.0.0
> If/else branch does not always infer the variable type
> --
>
> Key: GROOVY-5502
> URL: https://issues.apache.org/jira/browse/GROOVY-5502
> Project: Groovy
> Issue Type: Improvement
> Components: Static Type Checker
>Affects Versions: 2.0.0, 2.5.23, 4.0.14, 3.0.19
>Reporter: Ariel Morelli Andres
>Priority: Minor
>
> Suppose we have the following code:
> {code}
> class A {
> void m() {
> }
> }
> class B extends A {
> }
> class C extends A {
> }
> @groovy.transform.TypeChecked
> class Test {
>void m() {
> def var = new Object() //If instead I put just "def var" it works as
> spected
> if (true) {
> var = new B()
> }
> else {
> var = new C()
> }
> var.m() //fails here
>}
> }
> {code}
> In this case, after the if/else structure we can infer that var is instanceOf
> A.
> But, the initialization seems to confuse the type inference.
> [Static type checking] - Cannot find matching method java.lang.Object#mA()
> at line: 23, column: 7
> If instead of {code}def var = new Object(){code} we put just {code}def
> var{code}, then the inference works fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-5404) Compiler exception for invalid operator
[
https://issues.apache.org/jira/browse/GROOVY-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-5404.
--
Fix Version/s: 1.8.8
(was: 4.x)
Assignee: Jochen Theodorou
Resolution: Fixed
I am closing the issue because the bug behind got fixed and the message is now
different as well
> Compiler exception for invalid operator
> ---
>
> Key: GROOVY-5404
> URL: https://issues.apache.org/jira/browse/GROOVY-5404
> Project: Groovy
> Issue Type: Improvement
> Components: class generator
>Affects Versions: 1.8.6
>Reporter: Jan Stette
>Assignee: Jochen Theodorou
>Priority: Minor
> Fix For: 1.8.8
>
>
> A script containing this:
> print "Foo" ===~ ".*"
> ...causes the stack trace below from the compiler. It's not valid code of
> course, but the compiler should give a normal error message to the user.
> Stack trace:
> >>> a serious error occurred: BUG! exception in phase 'class generation' in
> >>> source unit '<...>Foo.groovy' Operation: ("===" at 2:13: "===" ) not
> >>> supported
> >>> stacktrace:
> BUG! exception in phase 'class generation' in source unit
> '/Users/jans/src/courses/nlp-class/week4/pa4-ner/java/GroovyTest.groovy'
> Operation: ("===" at 2:13: "===" ) not supported
> at
> org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.eval(BinaryExpressionHelper.java:246)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:521)
> at
> org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:49)
> at
> org.codehaus.groovy.classgen.asm.CallSiteWriter.makeCallSite(CallSiteWriter.java:301)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.makeCall(InvocationWriter.java:187)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.makeCall(InvocationWriter.java:89)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.makeInvokeMethodCall(InvocationWriter.java:73)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.writeInvokeMethod(InvocationWriter.java:292)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethodCallExpression(AsmClassGenerator.java:657)
> at
> org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
> at
> org.codehaus.groovy.classgen.asm.StatementWriter.writeReturn(StatementWriter.java:577)
> at
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeReturn(OptimizingStatementWriter.java:316)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitReturnStatement(AsmClassGenerator.java:499)
> at
> org.codehaus.groovy.ast.stmt.ReturnStatement.visit(ReturnStatement.java:47)
> at
> org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:80)
> at
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:155)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:449)
> at
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:101)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:112)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:313)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:270)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:390)
> at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1056)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:174)
> at
> org.codehaus.groovy.control.CompilationUnit$14.call(CompilationUnit.java:767)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:967)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:546)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:524)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:501)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:480)
> at
>
[jira] [Resolved] (GROOVY-5117) remove all references to java.util.logging from within groovy
[ https://issues.apache.org/jira/browse/GROOVY-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-5117. -- Assignee: Jochen Theodorou Resolution: Won't Fix I am closing this issue for now, since JUL bridges exist. If [~rzorzorzo] sees things different I invite him to reopen the discussion here. > remove all references to java.util.logging from within groovy > - > > Key: GROOVY-5117 > URL: https://issues.apache.org/jira/browse/GROOVY-5117 > Project: Groovy > Issue Type: Improvement > Environment: using groovy as script engine embedded within another > application/framework >Reporter: ron >Assignee: Jochen Theodorou >Priority: Major > > java does not allow multiple configurations of logging. > java logging is initialized on class load. > some applications (for example jboss 7) assume that they are the only ones to > initialize the logging and will crash if java logging has already been > initialized. > solution: add and use groovy logging class, which, depending on system > property configuration, may or may not use java.util.logging. > remove all references to java.util.logging from all groovy classes (for > example, org.codehaus.groovy.runtime.*) > -- Ron > http://sourceforge.net/projects/yajsw/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-5357) The accessor pair can't be provided from different sources
[
https://issues.apache.org/jira/browse/GROOVY-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-5357.
--
Fix Version/s: 4.0.0
3.0.3
Assignee: Jochen Theodorou
Resolution: Fixed
Closed as fixed per user comment
> The accessor pair can't be provided from different sources
> --
>
> Key: GROOVY-5357
> URL: https://issues.apache.org/jira/browse/GROOVY-5357
> Project: Groovy
> Issue Type: Sub-task
> Components: groovy-runtime
>Reporter: OC
>Assignee: Jochen Theodorou
>Priority: Major
> Fix For: 4.0.0, 3.0.3
>
>
> When one of the accessor pair is added through a mixin or metaclass, Groovy
> behaves as if the other one did not exist.
> Explanation kindly provided by Paul: "MetaClassImpl finds a MetaBeanProperty
> containing just the getter. When only a getter is found there is an incorrect
> assumption that a setter doesn't exist in the underlying class."
> {code}
> class Foo {
> void setVal(v) { println "setVal: $v" }
> }
> @Category(Foo) class Getter {
> def getVal() { println "getVal" }
> }
> class Test {
> static def main(av) {
> Foo.mixin Getter
> def f = new Foo()
> f.setVal('foo')
> f.val = null // => groovy.lang.ReadOnlyPropertyException: Cannot set
> readonly property: val for class: Foo
> }
> }
> {code}
> or
> {code}
> class Foo {
> void setVal(v) { println "setVal: $v" }
> }
> class Test {
> static def main(av) {
> Foo.metaClass.getVal={-> println "getval" }
> def f = new Foo()
> f.setVal('foo')
> f.val = null // => groovy.lang.ReadOnlyPropertyException: Cannot set
> readonly property: val for class: Foo
> }
> }
> {code}
> or
> {code}
> class Foo {
> def getVal() { println "getVal" }
> }
> class Test {
> static def main(av) {
> Foo.metaClass.setVal={v-> }
> def f = new Foo()
> f.getVal()
> f.val
> }
> }
> {code}
> etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-5399) Automatically provide instance methods on objects when another class has a static method with the object as first argument
[
https://issues.apache.org/jira/browse/GROOVY-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-5399.
--
Assignee: Jochen Theodorou
Resolution: Won't Fix
With default methods on interfaces Java more and more adds methods to
interfaces, that formerly would have gone in helper classes like Arrays and
Collections. I still think adding these kind of methods to DGM on demand is
better, but the need will probably also arise less. Thus it should be save to
close this feature request
> Automatically provide instance methods on objects when another class has a
> static method with the object as first argument
> --
>
> Key: GROOVY-5399
> URL: https://issues.apache.org/jira/browse/GROOVY-5399
> Project: Groovy
> Issue Type: New Feature
> Components: Compiler
>Reporter: Dr. Russel Winder
>Assignee: Jochen Theodorou
>Priority: Major
>
> The script:
> {code}
> number = 27
> println number.toHexString ( )
> {code}
> results in the message:
> {quote}
> Caught: groovy.lang.MissingMethodException: No signature of method:
> java.lang.Integer.toHexString() is applicable for argument types: () values:
> []
> Possible solutions: toHexString(int), toString(), toString(), toString(),
> toString(int), toString(int, int)
> groovy.lang.MissingMethodException: No signature of method:
> java.lang.Integer.toHexString() is applicable for argument types: () values:
> []
> Possible solutions: toHexString(int), toString(), toString(), toString(),
> toString(int), toString(int, int)
> at toHexString_Problem.run(toHexString_Problem.groovy:5)
> {quote}
> The reason is that _toHexString_ is defined as a static method on the types
> and not within the GroovyJDK. I believe that it is more usable for
> prograqmmers, more appropriate to a dynamic language, and generally more
> Groovy to allow the method to operate on a reference to an object and only
> raise an exception if the object is not of an appropriate type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-4985) null and .with{}
[
https://issues.apache.org/jira/browse/GROOVY-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-4985.
--
Assignee: Jochen Theodorou
Resolution: Duplicate
duplicate of GROOVY-4526
> null and .with{}
>
>
> Key: GROOVY-4985
> URL: https://issues.apache.org/jira/browse/GROOVY-4985
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.8.0
>Reporter: Nikita Y Volkov
>Assignee: Jochen Theodorou
>Priority: Major
> Attachments: 4985.patch
>
>
> Currently this fails:{code}
> null.with { assert it == null }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-4526) NullObject paradoxes
[
https://issues.apache.org/jira/browse/GROOVY-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-4526.
--
Fix Version/s: 1.8.0
Assignee: Jochen Theodorou
Resolution: Fixed
the issue got forgotten. The associated PR has been merged 10 years ago already
> NullObject paradoxes
>
>
> Key: GROOVY-4526
> URL: https://issues.apache.org/jira/browse/GROOVY-4526
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.7.5, 1.8-beta-2
>Reporter: Nikita Y Volkov
>Assignee: Jochen Theodorou
>Priority: Major
> Fix For: 1.8.0
>
>
> {code}
> def theNull = NullObject.getNullObject()
> assert theNull// first paradox
> assert theNull instanceof NullObject
> assert theNull.equals(null)
> assert theNull != null// second paradox
> assert null.getClass() == NullObject
> assert !(null instanceof NullObject) // third paradox
> {code}
> I have bumped into this paradox after debugging the following script:
> {code}
> new File('inexestent-folder/').listFiles().with { files ->
> assert files
> assert files in NullObject
> println "This shouldn't happen"
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-3825) Byte code generator (used by GroovyScriptEngine, GroovyShell & GroovyClassLoader) flag invalid methods
[ https://issues.apache.org/jira/browse/GROOVY-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-3825. -- Assignee: Jochen Theodorou Resolution: Fixed This has been fixed a long time ago. Should there still be cases for this we have to look at them specifically and in a new issue > Byte code generator (used by GroovyScriptEngine, GroovyShell & > GroovyClassLoader) flag invalid methods > -- > > Key: GROOVY-3825 > URL: https://issues.apache.org/jira/browse/GROOVY-3825 > Project: Groovy > Issue Type: Improvement > Components: class generator >Affects Versions: 1.6.5, 1.7-beta-2 >Reporter: jwb >Assignee: Jochen Theodorou >Priority: Minor > Labels: ClassFormatError > > When generating code for the Groovy compiler, one frequently exceeds the > Class file format limit on method size. The resulting ClassFormatError from > the ClassLoader doesn't effectively point at the problem. In addition, the > Error is not a type of Exception and so is not picked up by conventional > logging. > Ideally, the methods that generate class files would abort code-generation > and throw a type of Exception when the generated method exceeds the limit > imposed by the class file format. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-9718) Illegal reflective access operation to constructor sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS
[
https://issues.apache.org/jira/browse/GROOVY-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-9718.
--
Assignee: Jochen Theodorou
Resolution: Won't Fix
This is a problem in with OpenWebstart and the module system, not Groovy as such
> Illegal reflective access operation to constructor
> sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS
> ---
>
> Key: GROOVY-9718
> URL: https://issues.apache.org/jira/browse/GROOVY-9718
> Project: Groovy
> Issue Type: Bug
> Components: jdk conflict
>Affects Versions: 3.0.5
> Environment: OS: Linux Ubuntu 20.04.1 (Xubuntu flavor)
> JRE version: OpenJDK Runtime Environment 11.0.8 64-Bit
> Groovy Version: 3.0.5
>Reporter: Rolando Chaparro Fox
>Assignee: Jochen Theodorou
>Priority: Major
>
> Hello,
> The following piece of code triggers a Warning in Java 11:
> {code:java}
> import sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS as ModuleInitArgs
> // This CK_C_INITIALIZE_ARGS constructor call triggers the warning
> ModuleInitArgs initArgs = new ModuleInitArgs()
> {code}
> This is the Warning:
> {noformat}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.ReflectionUtils
> (file:/home/rchfox/somewhere/groovy-3.0.5.jar) to
> constructor sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.ReflectionUtils
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future
> release{noformat}
> The above constructor call works fine, nonetheless .
> Not quite sure, but apparently CK_C_INITIALIZE_ARGS has no explicit
> constructor. Here the source code at openjdk.java.net:
> [CK_C_INITIALIZE_ARGS.java|http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_C_INITIALIZE_ARGS.java]
> What I know is that this "constructor" call did not trigger any warning in
> Java <= 1.8.
> *Side note #1*: I kind of understand the Java designers' mindset. I guess
> that the idea behind this is not exposing implemented functionality required
> by callers of a function/method/constructor, so that the calling code
> awkwardly re-implements the same functionality in terms of those calls.
> Probably the OpenJDK crypto team guys expect nobody should ever need to
> invoke the CK_C_INITIALIZE_ARGS constructor. However, in my case in
> particular, I haven't found yet any sound programmatic alternative to
> implement the functionality I need.
> *Side note #2*: I managed to bypass this issue using the new {{--add-opens}}
> JVM argument (available since Java 9), as suggested in Oracle's [Migration
> Guide|https://docs.oracle.com/en/java/javase/11/migrate].
> However, I still need to solve this issue by other means because my app (a
> JavaFX/GroovyFX Application) is launched through JWS/JNLP, using the
> OpenWebStart implementation, which in turns has a bug right now that prevents
> me using the new {{--add-opens}} JVM argument, as I've just reported
> [here|https://github.com/karakun/OpenWebStart/issues/322].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-1367) allow cloning of the AST
[ https://issues.apache.org/jira/browse/GROOVY-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-1367. -- Resolution: Won't Fix The real need for this did never arise, so closing this > allow cloning of the AST > > > Key: GROOVY-1367 > URL: https://issues.apache.org/jira/browse/GROOVY-1367 > Project: Groovy > Issue Type: Sub-task > Components: Compiler >Reporter: Jochen Theodorou >Assignee: Jochen Theodorou >Priority: Major > > to allow cloning of the AST we need a cloning method that makes a deep copy. > Expressions have the transform method, but that may not return a new > instance. But for reusing AST parts in another AST we have to make a deep > copy. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GROOVY-1367) allow cloning of the AST
[ https://issues.apache.org/jira/browse/GROOVY-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou reassigned GROOVY-1367: Assignee: Jochen Theodorou > allow cloning of the AST > > > Key: GROOVY-1367 > URL: https://issues.apache.org/jira/browse/GROOVY-1367 > Project: Groovy > Issue Type: Sub-task > Components: Compiler >Reporter: Jochen Theodorou >Assignee: Jochen Theodorou >Priority: Major > > to allow cloning of the AST we need a cloning method that makes a deep copy. > Expressions have the transform method, but that may not return a new > instance. But for reusing AST parts in another AST we have to make a deep > copy. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-9493) JSR 223 regression: not working under OpenJ9 since version 3.0.0
[ https://issues.apache.org/jira/browse/GROOVY-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-9493. -- Resolution: Not A Bug It seems the issue is no longer one as it seems a new release of J9 fixed the issue > JSR 223 regression: not working under OpenJ9 since version 3.0.0 > > > Key: GROOVY-9493 > URL: https://issues.apache.org/jira/browse/GROOVY-9493 > Project: Groovy > Issue Type: Bug > Components: groovy-jsr223 >Affects Versions: 3.0.0, 3.0.1, 3.0.2 >Reporter: Danilo Pianini >Assignee: Jochen Theodorou >Priority: Major > > Since version 3.0.0, Groovy fails at running JSR 223 scripts under OpenJ9. > The issue does not appear under OpenJDK. > > The following is the result of the attempted evaluation of the script `1` > under OpenJ9 12. The failure is reproducible with OpenJ9 11 and OpenJ9 14. > Inside `GroovyScriptEngineImpl`, parameter `script` has value `"1"` (meaning > a string of length 1 with the sole number 1 as content). > > ``` > java.lang.NullPointerExceptionjava.lang.NullPointerException at > groovy.lang.GroovyClassLoader$InnerLoader.setDefaultAssertionStatus(GroovyClassLoader.java:617) > at > java.base/java.lang.ClassLoader.initializeClassLoaderAssertStatus(ClassLoader.java:1990) > at java.base/java.lang.ClassLoader.(ClassLoader.java:344) at > java.base/java.lang.ClassLoader.(ClassLoader.java:284) at > java.base/java.security.SecureClassLoader.(SecureClassLoader.java:77) > at java.base/java.net.URLClassLoader.(URLClassLoader.java:232) at > groovy.lang.GroovyClassLoader.(GroovyClassLoader.java:158) at > groovy.lang.GroovyClassLoader.(GroovyClassLoader.java:147) at > groovy.lang.GroovyClassLoader$InnerLoader.(GroovyClassLoader.java:472) > at > groovy.lang.GroovyClassLoader.lambda$createCollector$4(GroovyClassLoader.java:671) > at groovy.lang.GroovyClassLoader$$Lambda$397.283EE5D0.run(Unknown > Source) at > java.base/java.security.AccessController.doPrivileged(AccessController.java:678) > at groovy.lang.GroovyClassLoader.createCollector(GroovyClassLoader.java:671) > at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:385) at > groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332) > at groovy.lang.GroovyClassLoader$$Lambda$345.284B4BF0.provide(Unknown > Source) at > org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163) > at > org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154) > at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330) at > groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314) at > groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:257) at > org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.getScriptClass(GroovyScriptEngineImpl.java:336) > at > org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:153) > at > java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233) > at > it.unibo.alchemist.loader.variables.JSR223Variable.getWith(JSR223Variable.kt:39) > at it.unibo.alchemist.loader.YamlLoader.(YamlLoader.java:287) at > it.unibo.alchemist.loader.YamlLoader.(YamlLoader.java:220) at > it.unibo.alchemist.SimulationLauncher.launch(SimulationLauncher.kt:42) at > it.unibo.alchemist.Launcher$DefaultImpls.invoke(Launcher.kt:20) at > it.unibo.alchemist.SimulationLauncher.invoke(SimulationLauncher.kt:27) at > it.unibo.alchemist.Alchemist.main(Alchemist.kt:115) at > TestCLIKt$runWithOptions$exit$1.invoke(TestCLI.kt:48) at > TestCLIKt$runWithOptions$exit$1.invoke(TestCLI.kt) at > TestCLIKt.runCatchingExit(TestCLI.kt:38) at > TestCLIKt.runWithOptions(TestCLI.kt:47) at > TestCLI$1$2.invokeSuspend(TestCLI.kt:69) at TestCLI$1$2.invoke(TestCLI.kt) at > io.kotlintest.runner.jvm.TestCaseExecutor$executeTest$supervisorJob$1$invokeSuspend$$inlined$map$lambda$1.invokeSuspend(TestCaseExecutor.kt:121) > at > kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) > at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56) at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:831) > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GROOVY-9493) JSR 223 regression: not working under OpenJ9 since version 3.0.0
[ https://issues.apache.org/jira/browse/GROOVY-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou reassigned GROOVY-9493: Assignee: Jochen Theodorou > JSR 223 regression: not working under OpenJ9 since version 3.0.0 > > > Key: GROOVY-9493 > URL: https://issues.apache.org/jira/browse/GROOVY-9493 > Project: Groovy > Issue Type: Bug > Components: groovy-jsr223 >Affects Versions: 3.0.0, 3.0.1, 3.0.2 >Reporter: Danilo Pianini >Assignee: Jochen Theodorou >Priority: Major > > Since version 3.0.0, Groovy fails at running JSR 223 scripts under OpenJ9. > The issue does not appear under OpenJDK. > > The following is the result of the attempted evaluation of the script `1` > under OpenJ9 12. The failure is reproducible with OpenJ9 11 and OpenJ9 14. > Inside `GroovyScriptEngineImpl`, parameter `script` has value `"1"` (meaning > a string of length 1 with the sole number 1 as content). > > ``` > java.lang.NullPointerExceptionjava.lang.NullPointerException at > groovy.lang.GroovyClassLoader$InnerLoader.setDefaultAssertionStatus(GroovyClassLoader.java:617) > at > java.base/java.lang.ClassLoader.initializeClassLoaderAssertStatus(ClassLoader.java:1990) > at java.base/java.lang.ClassLoader.(ClassLoader.java:344) at > java.base/java.lang.ClassLoader.(ClassLoader.java:284) at > java.base/java.security.SecureClassLoader.(SecureClassLoader.java:77) > at java.base/java.net.URLClassLoader.(URLClassLoader.java:232) at > groovy.lang.GroovyClassLoader.(GroovyClassLoader.java:158) at > groovy.lang.GroovyClassLoader.(GroovyClassLoader.java:147) at > groovy.lang.GroovyClassLoader$InnerLoader.(GroovyClassLoader.java:472) > at > groovy.lang.GroovyClassLoader.lambda$createCollector$4(GroovyClassLoader.java:671) > at groovy.lang.GroovyClassLoader$$Lambda$397.283EE5D0.run(Unknown > Source) at > java.base/java.security.AccessController.doPrivileged(AccessController.java:678) > at groovy.lang.GroovyClassLoader.createCollector(GroovyClassLoader.java:671) > at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:385) at > groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332) > at groovy.lang.GroovyClassLoader$$Lambda$345.284B4BF0.provide(Unknown > Source) at > org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163) > at > org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154) > at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330) at > groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314) at > groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:257) at > org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.getScriptClass(GroovyScriptEngineImpl.java:336) > at > org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:153) > at > java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233) > at > it.unibo.alchemist.loader.variables.JSR223Variable.getWith(JSR223Variable.kt:39) > at it.unibo.alchemist.loader.YamlLoader.(YamlLoader.java:287) at > it.unibo.alchemist.loader.YamlLoader.(YamlLoader.java:220) at > it.unibo.alchemist.SimulationLauncher.launch(SimulationLauncher.kt:42) at > it.unibo.alchemist.Launcher$DefaultImpls.invoke(Launcher.kt:20) at > it.unibo.alchemist.SimulationLauncher.invoke(SimulationLauncher.kt:27) at > it.unibo.alchemist.Alchemist.main(Alchemist.kt:115) at > TestCLIKt$runWithOptions$exit$1.invoke(TestCLI.kt:48) at > TestCLIKt$runWithOptions$exit$1.invoke(TestCLI.kt) at > TestCLIKt.runCatchingExit(TestCLI.kt:38) at > TestCLIKt.runWithOptions(TestCLI.kt:47) at > TestCLI$1$2.invokeSuspend(TestCLI.kt:69) at TestCLI$1$2.invoke(TestCLI.kt) at > io.kotlintest.runner.jvm.TestCaseExecutor$executeTest$supervisorJob$1$invokeSuspend$$inlined$map$lambda$1.invokeSuspend(TestCaseExecutor.kt:121) > at > kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) > at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56) at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:831) > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11158) Explore whether we should deprecate/delete any generated callsite caching related classes
[ https://issues.apache.org/jira/browse/GROOVY-11158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756090#comment-17756090 ] Jochen Theodorou commented on GROOVY-11158: --- I created https://github.com/apache/groovy/pull/1934 to give an impression of the impact of the callsite caching code. > Explore whether we should deprecate/delete any generated callsite caching > related classes > - > > Key: GROOVY-11158 > URL: https://issues.apache.org/jira/browse/GROOVY-11158 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Priority: Major > Fix For: 5.x > > > See the mailing list discussion: > https://lists.apache.org/thread/hvfxv7j9bnrj6l48c1hnd7px4qhdn7b7 > We want to retain any classes needed for backwards compatibility, e.g. > classes embedded in the bytecode generated from older groovy versions. But we > should deprecate classes as appropriate. Some may be possible to delete > altogether. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11159) ClassNode: separate type definition information
[ https://issues.apache.org/jira/browse/GROOVY-11159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755952#comment-17755952 ] Jochen Theodorou commented on GROOVY-11159: --- I would do for example TypeReference, ClassNode and maybe something like ResolvedClass. in class A extends B, A would become a ClassNode with all the fields and methods, B would be a TypeReference maybe to be resolved by the compiler. If B is backed by a to be compiled class, it points to a ClassNode, otherwise it would point to a ResolvedClass. And maybe I would even have another class you can use to get all the fields and methods from, which you get from ResolvedClass and maybe also ClassNode. Then we could move the lazy init to that part Of course ClassNode would not need the lazy init anymore in this scenario. Well, just an idea. and of course it will break about every transform there is. > ClassNode: separate type definition information > --- > > Key: GROOVY-11159 > URL: https://issues.apache.org/jira/browse/GROOVY-11159 > Project: Groovy > Issue Type: Improvement >Reporter: Eric Milles >Priority: Minor > > ClassNode is used to represent type definitions as well as type references. > There are a lot of data members that apply only to type definitions. > However, every reference pays the cost. ClassNode could have a single > reference to another class (essentially a struct) that holds all the > definition information. With this, type references would only have one > reference (initialized to null) instead of all those fields. > Fields: > * modifiers > * syntheticPublic > * superClass > * interfaces > * mixins > * objectInitializers > * constructors > * methods > * methodsList > * fields > * properties > * fieldIndex > * module > * compileUnit > * staticClass > * scriptBody > * script > * innerClasses > * transformInstances? > * lazyInitDone > * lazyInitLock > * clazz > * permittedSubclasses > * recordComponents -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11154) Script subclasses cannot have constructors with arguments
[
https://issues.apache.org/jira/browse/GROOVY-11154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755621#comment-17755621
]
Jochen Theodorou commented on GROOVY-11154:
---
Thinking out loud: How and when do you identify the unused constructors?
Normally I would have said that we add the constructors much later, like we do
for normal classes. But GROOVY-8096 sounds like a problem for that. We could
mark them as synthetic and then the ones from @InheritConstrcutors would not be
synthetic... But is a rule "if there is a non-synthetic constructor in a
generated script class remove all synthetic ones" sound? Maybe worth a try.
But if one would indeed use @Field and @InheritConstructors in the phases they
are intended to be used, then this will not work, as field is running first and
would modify the wrong constructor.
Maybe we should instead apply InheritConstructors early? If the script base
class is set, we take it from there, otherwise from the given class... And
then @BaseScript is in the way.. sigh.
Or another idea we add a fake constructor to the script, let transforms run
wild with it and then use the contents of that constructor to add it to other
added constructors in a later phase That way the base script would be
resolved, Field would have already added its fields to the constructor and that
code would be copied then to the constructors added by the inherit transform...
still sounds messy to me, but could work.
> Script subclasses cannot have constructors with arguments
> -
>
> Key: GROOVY-11154
> URL: https://issues.apache.org/jira/browse/GROOVY-11154
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.7
>Reporter: jonny
>Priority: Major
>
> Prior to the fix for GROOVY-9857, subclasses of {{Script}} could have
> constructor arguments and still be used (with a little help from
> {{InheritConstructors}} and {{DefaultGroovyMethods#newInstance}}).
> For example, the following script executes find in Groovy 3.x, but fails
> after Groovy 4.0.7:
> {code}
> import groovy.transform.InheritConstructors
> import org.codehaus.groovy.ast.AnnotationNode
> import org.codehaus.groovy.ast.ClassNode
> import org.codehaus.groovy.classgen.GeneratorContext
> import org.codehaus.groovy.control.CompilationFailedException
> import org.codehaus.groovy.control.CompilePhase
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.SourceUnit
> import org.codehaus.groovy.control.customizers.CompilationCustomizer
> import org.codehaus.groovy.runtime.DefaultGroovyMethods
> abstract class NamedScript extends Script {
> NamedScript(String name) {
> }
> }
> def compilerConfig = new CompilerConfiguration()
> compilerConfig.setScriptBaseClass(NamedScript.class.getName())
> compilerConfig.addCompilationCustomizers(new
> CompilationCustomizer(CompilePhase.CONVERSION) {
> @Override
> void call(SourceUnit source, GeneratorContext context, ClassNode
> classNode) throws CompilationFailedException {
> classNode.addAnnotation(new AnnotationNode(new
> ClassNode(InheritConstructors.class)))
> }
> })
> def classLoader = new GroovyClassLoader(new GroovyClassLoader(),
> compilerConfig)
> def parsedClass = classLoader.parseClass('println "Foo"')
> DefaultGroovyMethods.newInstance(parsedClass, "dummy").run()
> {code}
> The error returned is:
> {noformat}
> Implicit super constructor NamedScript() is undefined for generated
> constructor. Must define an explicit constructor.
> {noformat}
> Ratpack relies on this behavior for its custom text template renderer.
> See how script objects are instantiated in the
> [ScriptEngine#create|https://github.com/ratpack/ratpack/blob/503060ab2351a49f6e96416d588607ff7ef63028/ratpack-groovy/src/main/java/ratpack/groovy/script/internal/ScriptEngine.java#L51]
> method.
> I talked this out in the Groovy community Slack with [~blackdrag] (see
> [thread|https://groovy-community.slack.com/archives/C2NEFCM55/p1691783910137829]),
> who suggested that we should skip the check for constructors for Script
> subclasses as a bugfix in Groovy 4, with a potentially breaking change in
> Groovy 5 to make constructor generation for Script subclasses happen in the
> same place as any other class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11158) Explore whether we should deprecate/delete any generated callsite caching related classes
[ https://issues.apache.org/jira/browse/GROOVY-11158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755584#comment-17755584 ] Jochen Theodorou edited comment on GROOVY-11158 at 8/17/23 2:42 PM: After looking more closely I think there is actually quite a few places that would require adaption, including breaking changes. was (Author: blackdrag): After looking more closely I tihnk there is actually quite a few places that would require adaption, including breaking changes. > Explore whether we should deprecate/delete any generated callsite caching > related classes > - > > Key: GROOVY-11158 > URL: https://issues.apache.org/jira/browse/GROOVY-11158 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Priority: Major > Fix For: 5.x > > > See the mailing list discussion: > https://lists.apache.org/thread/hvfxv7j9bnrj6l48c1hnd7px4qhdn7b7 > We want to retain any classes needed for backwards compatibility, e.g. > classes embedded in the bytecode generated from older groovy versions. But we > should deprecate classes as appropriate. Some may be possible to delete > altogether. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11158) Explore whether we should deprecate/delete any generated callsite caching related classes
[ https://issues.apache.org/jira/browse/GROOVY-11158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755584#comment-17755584 ] Jochen Theodorou commented on GROOVY-11158: --- After looking more closely I tihnk there is actually quite a few places that would require adaption, including breaking changes. > Explore whether we should deprecate/delete any generated callsite caching > related classes > - > > Key: GROOVY-11158 > URL: https://issues.apache.org/jira/browse/GROOVY-11158 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Priority: Major > Fix For: 5.x > > > See the mailing list discussion: > https://lists.apache.org/thread/hvfxv7j9bnrj6l48c1hnd7px4qhdn7b7 > We want to retain any classes needed for backwards compatibility, e.g. > classes embedded in the bytecode generated from older groovy versions. But we > should deprecate classes as appropriate. Some may be possible to delete > altogether. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11158) Explore whether we should deprecate/delete any generated callsite caching related classes
[ https://issues.apache.org/jira/browse/GROOVY-11158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755580#comment-17755580 ] Jochen Theodorou commented on GROOVY-11158: --- My wish would be to "long term" to take the all classes in org.codehaus.groovy.runtime.callsite, make them deprecated and move them to a groovy-lagacy kind of jar, that is then only required if you want to run groovy with callsite caching. I think only CachedClass#getCallSiteLoader would also have to be moved, causing a breaking change in the public api. Though I think the risk is really low > Explore whether we should deprecate/delete any generated callsite caching > related classes > - > > Key: GROOVY-11158 > URL: https://issues.apache.org/jira/browse/GROOVY-11158 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Priority: Major > Fix For: 5.x > > > See the mailing list discussion: > https://lists.apache.org/thread/hvfxv7j9bnrj6l48c1hnd7px4qhdn7b7 > We want to retain any classes needed for backwards compatibility, e.g. > classes embedded in the bytecode generated from older groovy versions. But we > should deprecate classes as appropriate. Some may be possible to delete > altogether. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11154) Script subclasses cannot have constructors with arguments
[
https://issues.apache.org/jira/browse/GROOVY-11154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755578#comment-17755578
]
Jochen Theodorou commented on GROOVY-11154:
---
I forgot the later part of the question.. does this generate a constructor that
passes name through to NamedScript? Yes, it does. In other words 3 constructor
would exist, of which 2 are added by us and they contain super() or
super(binding), which both do not match available constructors in NamedScript.
@InheritConstructors adds a third one, which basically does super(name). Before
the check, the two duds we add wouldn't have been a problem since they are not
called. With the check they are correctly recognized as wrong.
> Script subclasses cannot have constructors with arguments
> -
>
> Key: GROOVY-11154
> URL: https://issues.apache.org/jira/browse/GROOVY-11154
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.7
>Reporter: jonny
>Priority: Major
>
> Prior to the fix for GROOVY-9857, subclasses of {{Script}} could have
> constructor arguments and still be used (with a little help from
> {{InheritConstructors}} and {{DefaultGroovyMethods#newInstance}}).
> For example, the following script executes find in Groovy 3.x, but fails
> after Groovy 4.0.7:
> {code}
> import groovy.transform.InheritConstructors
> import org.codehaus.groovy.ast.AnnotationNode
> import org.codehaus.groovy.ast.ClassNode
> import org.codehaus.groovy.classgen.GeneratorContext
> import org.codehaus.groovy.control.CompilationFailedException
> import org.codehaus.groovy.control.CompilePhase
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.SourceUnit
> import org.codehaus.groovy.control.customizers.CompilationCustomizer
> import org.codehaus.groovy.runtime.DefaultGroovyMethods
> abstract class NamedScript extends Script {
> NamedScript(String name) {
> }
> }
> def compilerConfig = new CompilerConfiguration()
> compilerConfig.setScriptBaseClass(NamedScript.class.getName())
> compilerConfig.addCompilationCustomizers(new
> CompilationCustomizer(CompilePhase.CONVERSION) {
> @Override
> void call(SourceUnit source, GeneratorContext context, ClassNode
> classNode) throws CompilationFailedException {
> classNode.addAnnotation(new AnnotationNode(new
> ClassNode(InheritConstructors.class)))
> }
> })
> def classLoader = new GroovyClassLoader(new GroovyClassLoader(),
> compilerConfig)
> def parsedClass = classLoader.parseClass('println "Foo"')
> DefaultGroovyMethods.newInstance(parsedClass, "dummy").run()
> {code}
> The error returned is:
> {noformat}
> Implicit super constructor NamedScript() is undefined for generated
> constructor. Must define an explicit constructor.
> {noformat}
> Ratpack relies on this behavior for its custom text template renderer.
> See how script objects are instantiated in the
> [ScriptEngine#create|https://github.com/ratpack/ratpack/blob/503060ab2351a49f6e96416d588607ff7ef63028/ratpack-groovy/src/main/java/ratpack/groovy/script/internal/ScriptEngine.java#L51]
> method.
> I talked this out in the Groovy community Slack with [~blackdrag] (see
> [thread|https://groovy-community.slack.com/archives/C2NEFCM55/p1691783910137829]),
> who suggested that we should skip the check for constructors for Script
> subclasses as a bugfix in Groovy 4, with a potentially breaking change in
> Groovy 5 to make constructor generation for Script subclasses happen in the
> same place as any other class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11154) Script subclasses cannot have constructors with arguments
[
https://issues.apache.org/jira/browse/GROOVY-11154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1779#comment-1779
]
Jochen Theodorou commented on GROOVY-11154:
---
[~emilles] ratpack adds @InheritConstructors by compiler customizer and the
script base class by compiler configuration. Meaning the @BaseScript annotation
is not used.
> Script subclasses cannot have constructors with arguments
> -
>
> Key: GROOVY-11154
> URL: https://issues.apache.org/jira/browse/GROOVY-11154
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.7
>Reporter: jonny
>Priority: Major
>
> Prior to the fix for GROOVY-9857, subclasses of {{Script}} could have
> constructor arguments and still be used (with a little help from
> {{InheritConstructors}} and {{DefaultGroovyMethods#newInstance}}).
> For example, the following script executes find in Groovy 3.x, but fails
> after Groovy 4.0.7:
> {code}
> import groovy.transform.InheritConstructors
> import org.codehaus.groovy.ast.AnnotationNode
> import org.codehaus.groovy.ast.ClassNode
> import org.codehaus.groovy.classgen.GeneratorContext
> import org.codehaus.groovy.control.CompilationFailedException
> import org.codehaus.groovy.control.CompilePhase
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.SourceUnit
> import org.codehaus.groovy.control.customizers.CompilationCustomizer
> import org.codehaus.groovy.runtime.DefaultGroovyMethods
> abstract class NamedScript extends Script {
> NamedScript(String name) {
> }
> }
> def compilerConfig = new CompilerConfiguration()
> compilerConfig.setScriptBaseClass(NamedScript.class.getName())
> compilerConfig.addCompilationCustomizers(new
> CompilationCustomizer(CompilePhase.CONVERSION) {
> @Override
> void call(SourceUnit source, GeneratorContext context, ClassNode
> classNode) throws CompilationFailedException {
> classNode.addAnnotation(new AnnotationNode(new
> ClassNode(InheritConstructors.class)))
> }
> })
> def classLoader = new GroovyClassLoader(new GroovyClassLoader(),
> compilerConfig)
> def parsedClass = classLoader.parseClass('println "Foo"')
> DefaultGroovyMethods.newInstance(parsedClass, "dummy").run()
> {code}
> The error returned is:
> {noformat}
> Implicit super constructor NamedScript() is undefined for generated
> constructor. Must define an explicit constructor.
> {noformat}
> Ratpack relies on this behavior for its custom text template renderer.
> See how script objects are instantiated in the
> [ScriptEngine#create|https://github.com/ratpack/ratpack/blob/503060ab2351a49f6e96416d588607ff7ef63028/ratpack-groovy/src/main/java/ratpack/groovy/script/internal/ScriptEngine.java#L51]
> method.
> I talked this out in the Groovy community Slack with [~blackdrag] (see
> [thread|https://groovy-community.slack.com/archives/C2NEFCM55/p1691783910137829]),
> who suggested that we should skip the check for constructors for Script
> subclasses as a bugfix in Groovy 4, with a potentially breaking change in
> Groovy 5 to make constructor generation for Script subclasses happen in the
> same place as any other class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11156) Groovy using no longer existing MagicAccessorImpl from sun.reflect
Jochen Theodorou created GROOVY-11156: - Summary: Groovy using no longer existing MagicAccessorImpl from sun.reflect Key: GROOVY-11156 URL: https://issues.apache.org/jira/browse/GROOVY-11156 Project: Groovy Issue Type: Improvement Reporter: Jochen Theodorou Since Java9 MagicAccessorImpl moved to a different package and does no longer fulfill the same role as before. While our code does not depend on that class to exist, it is also used almost solely for callsite caching code generation, which is no longer the default. Therefore removing the usage of class seems to be a good option at least for Groovy 5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11145) add a join() method for Iterable/List
[
https://issues.apache.org/jira/browse/GROOVY-11145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750438#comment-17750438
]
Jochen Theodorou commented on GROOVY-11145:
---
I think we made the design decision that implicit arguments are not supported
by static compilation. In fact we wanted it out of dynamic Groovy as well.
> add a join() method for Iterable/List
> -
>
> Key: GROOVY-11145
> URL: https://issues.apache.org/jira/browse/GROOVY-11145
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.5.12, 3.0.9, 4.0.13
>Reporter: Jochen Theodorou
>Priority: Minor
>
> {code:Java}
> @groovy.transform.CompileStatic
> def m() {
> ["a", "b"].join()
> }
> assert m() == "ab"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11143) Add extension method to source unit (same locality as static import)
[
https://issues.apache.org/jira/browse/GROOVY-11143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750428#comment-17750428
]
Jochen Theodorou commented on GROOVY-11143:
---
Yeah, that explains it in great detail for me. Originally the plan was to have
multiple switch points, depending on at least some receiver types. Then one
such change would not affect *all* method handles created so far. Never got
that far, and this is actually the first time a need for this pops up. But very
valid, yes
> Add extension method to source unit (same locality as static import)
>
>
> Key: GROOVY-11143
> URL: https://issues.apache.org/jira/browse/GROOVY-11143
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Eric Milles
>Priority: Major
>
> I have been poking around with the many ways to extend a class/object's
> functionality within groovy. To add a new method that can be called like any
> other instance method, there are a few possibilities:
> 1. modify the MetaClass
> {code:groovy}
> String.metaClass.ext = { ->
> print delegate
> }
> "works".ext()
> {code}
> 2. use a category class
> {code:groovy}
> @Category(String) class Cat {
> void ext() {
> println this
> }
> }
> use (Cat) {
> "works".ext()
> }
> {code}
> 3. apply a mixin
> first create class similar to Cat in (2)
> {code:groovy}
> def str = "works"; str.metaClass.mixin(Cat)
> str.ext()
> {code}
> 4. apply a trait
> {code:groovy}
> trait Ext {
> void ext() { println this.toLowerCase() } // see GROOVY-11142
> }
> "works".withTraits(Ext).ext()
> {code}
> 5. create an extension moodule
> - create class similar to Cat in (2)
> - create META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule file
> - build and deploy separately from current script / project
> What I'm after is something that works as easily in a script or source file
> as static imports but lets me call like an extension method. And does not
> modify state outside of the current script (like {{MetaClass}}) or introduce
> a thread barrier (like {{use}}). And works with static type checking.
> Scala has an "extension" mechanism that is similar to static import but there
> is a keyword on the category class that lets compiler know the method is used
> like any other instance method. Scala used to provide "implicit" methods --
> I've lost my familiarity with those.
> I've seen "import static extension foo.Bar.baz;" for some language.
> (citation required)
> And lastly, Kotlin provides a local extension like this:
> {code}
> fun foo.Bar.baz() { x ->
> // ...
> }
> {code}
> For any new users or just to add something quickly that can be used in a
> file, I think I'm looking for an enhancement to "import static ..." that will
> get substituted in the source unit, like {{StaticImportVisitor}} does today
> for static method calls. For example:
> {code:groovy}
> import static foo.Bar.baz
> import static /*something*/ foo.Bar.baz
> baz("") // supported by first import
> "".baz() // supported by second import
> {code}
> I have been considering whether "extension", "default", some annotation or
> something else should be used for /\*something\*/ in the script above.
> Similar to Kotlin, this could let someone declare an extension in a single
> script with no dynamic runtime impact:
> {code:groovy}
> import static /*something*/ ThisScript.*
> static ext(String self) {
> print self
> }
> "works".ext()
> {code}
> Has anyone looked at something like this in Groovy or other languages and has
> some feedback?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11145) add a join() method for Iterable/List
[
https://issues.apache.org/jira/browse/GROOVY-11145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-11145:
--
Description:
{code:Java}
@groovy.transform.CompileStatic
def m() {
["a", "b"].join()
}
assert m() == "ab"
{code}
was:
{code:Java}
@groovy.transform.CompileStatic
def m() {
["a", "b"].join()
}
assert m() == "ab"
{code}
I expected the code above to work since there is a join(Iterable) method in
DGM, but the code gives instead a compilation error. Works of course in dynamic
mode.
Summary: add a join() method for Iterable/List (was: Iterable DGM not
recognized for List)
> add a join() method for Iterable/List
> -
>
> Key: GROOVY-11145
> URL: https://issues.apache.org/jira/browse/GROOVY-11145
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.5.12, 3.0.9, 4.0.13
>Reporter: Jochen Theodorou
>Priority: Major
>
> {code:Java}
> @groovy.transform.CompileStatic
> def m() {
> ["a", "b"].join()
> }
> assert m() == "ab"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11145) add a join() method for Iterable/List
[
https://issues.apache.org/jira/browse/GROOVY-11145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-11145:
--
Issue Type: Improvement (was: Bug)
> add a join() method for Iterable/List
> -
>
> Key: GROOVY-11145
> URL: https://issues.apache.org/jira/browse/GROOVY-11145
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.5.12, 3.0.9, 4.0.13
>Reporter: Jochen Theodorou
>Priority: Major
>
> {code:Java}
> @groovy.transform.CompileStatic
> def m() {
> ["a", "b"].join()
> }
> assert m() == "ab"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11145) add a join() method for Iterable/List
[
https://issues.apache.org/jira/browse/GROOVY-11145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750271#comment-17750271
]
Jochen Theodorou commented on GROOVY-11145:
---
I updated the issue
> add a join() method for Iterable/List
> -
>
> Key: GROOVY-11145
> URL: https://issues.apache.org/jira/browse/GROOVY-11145
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.5.12, 3.0.9, 4.0.13
>Reporter: Jochen Theodorou
>Priority: Major
>
> {code:Java}
> @groovy.transform.CompileStatic
> def m() {
> ["a", "b"].join()
> }
> assert m() == "ab"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11145) Iterable DGM not recognized for List
Jochen Theodorou created GROOVY-11145:
-
Summary: Iterable DGM not recognized for List
Key: GROOVY-11145
URL: https://issues.apache.org/jira/browse/GROOVY-11145
Project: Groovy
Issue Type: Bug
Components: Static compilation, Static Type Checker
Affects Versions: 4.0.13, 3.0.9, 2.5.12
Reporter: Jochen Theodorou
{code:Java}
@groovy.transform.CompileStatic
def m() {
["a", "b"].join()
}
assert m() == "ab"
{code}
I expected the code above to work since there is a join(Iterable) method in
DGM, but the code gives instead a compilation error. Works of course in dynamic
mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11143) Add extension method to source unit (same locality as static import)
[
https://issues.apache.org/jira/browse/GROOVY-11143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750238#comment-17750238
]
Jochen Theodorou commented on GROOVY-11143:
---
[~emilles] "The use method creates a thread barrier so we can’t call it in our
server process." Can you explain a bit what the problem with the server process
is?
> Add extension method to source unit (same locality as static import)
>
>
> Key: GROOVY-11143
> URL: https://issues.apache.org/jira/browse/GROOVY-11143
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Eric Milles
>Priority: Major
>
> I have been poking around with the many ways to extend a class/object's
> functionality within groovy. To add a new method that can be called like any
> other instance method, there are a few possibilities:
> 1. modify the MetaClass
> {code:groovy}
> String.metaClass.ext = { ->
> print delegate
> }
> "works".ext()
> {code}
> 2. use a category class
> {code:groovy}
> @Category(String) class Cat {
> void ext() {
> println this
> }
> }
> use (Cat) {
> "works".ext()
> }
> {code}
> 3. apply a mixin
> first create class similar to Cat in (2)
> {code:groovy}
> def str = "works"; str.metaClass.mixin(Cat)
> str.ext()
> {code}
> 4. apply a trait
> {code:groovy}
> trait Ext {
> void ext() { println this.toLowerCase() } // see GROOVY-11142
> }
> "works".withTraits(Ext).ext()
> {code}
> 5. create an extension moodule
> - create class similar to Cat in (2)
> - create META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule file
> - build and deploy separately from current script / project
> What I'm after is something that works as easily in a script or source file
> as static imports but lets me call like an extension method. And does not
> modify state outside of the current script (like {{MetaClass}}) or introduce
> a thread barrier (like {{use}}). And works with static type checking.
> Scala has an "extension" mechanism that is similar to static import but there
> is a keyword on the category class that lets compiler know the method is used
> like any other instance method. Scala used to provide "implicit" methods --
> I've lost my familiarity with those.
> I've seen "import static extension foo.Bar.baz;" for some language.
> (citation required)
> And lastly, Kotlin provides a local extension like this:
> {code}
> fun foo.Bar.baz() { x ->
> // ...
> }
> {code}
> For any new users or just to add something quickly that can be used in a
> file, I think I'm looking for an enhancement to "import static ..." that will
> get substituted in the source unit, like {{StaticImportVisitor}} does today
> for static method calls. For example:
> {code:groovy}
> import static foo.Bar.baz
> import static /*something*/ foo.Bar.baz
> baz("") // supported by first import
> "".baz() // supported by second import
> {code}
> I have been considering whether "extension", "default", some annotation or
> something else should be used for /\*something\*/ in the script above.
> Similar to Kotlin, this could let someone declare an extension in a single
> script with no dynamic runtime impact:
> {code:groovy}
> import static /*something*/ ThisScript.*
> static ext(String self) {
> print self
> }
> "works".ext()
> {code}
> Has anyone looked at something like this in Groovy or other languages and has
> some feedback?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11143) Add extension method to source unit (same locality as static import)
[
https://issues.apache.org/jira/browse/GROOVY-11143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750028#comment-17750028
]
Jochen Theodorou commented on GROOVY-11143:
---
It depends on if you want to limit the visibility of the added method or not.
Restricting the visibility makes things quite difficult
> Add extension method to source unit (same locality as static import)
>
>
> Key: GROOVY-11143
> URL: https://issues.apache.org/jira/browse/GROOVY-11143
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Eric Milles
>Priority: Major
>
> I have been poking around with the many ways to extend a class/object's
> functionality within groovy. To add a new method that can be called like any
> other instance method, there are a few possibilities:
> 1. modify the MetaClass
> {code:groovy}
> String.metaClass.ext = { ->
> print delegate
> }
> "works".ext()
> {code}
> 2. use a category class
> {code:groovy}
> @Category(String) class Cat {
> void ext() {
> println this
> }
> }
> use (Cat) {
> "works".ext()
> }
> {code}
> 3. apply a mixin
> first create class similar to Cat in (2)
> {code:groovy}
> def str = "works"; str.metaClass.mixin(Cat)
> str.ext()
> {code}
> 4. apply a trait
> {code:groovy}
> trait Ext {
> void ext() { println this.toLowerCase() } // see GROOVY-11142
> }
> "works".withTraits(Ext).ext()
> {code}
> 5. create an extension moodule
> - create class similar to Cat in (2)
> - create META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule file
> - build and deploy separately from current script / project
> What I'm after is something that works as easily in a script or source file
> as static imports but lets me call like an extension method. And does not
> modify state outside of the current script (like {{MetaClass}}) or introduce
> a thread barrier (like {{use}}). And works with static type checking.
> Scala has an "extension" mechanism that is similar to static import but there
> is a keyword on the category class that lets compiler know the method is used
> like any other instance method. Scala used to provide "implicit" methods --
> I've lost my familiarity with those.
> I've seen "import static extension foo.Bar.baz;" for some language.
> (citation required)
> And lastly, Kotlin provides a local extension like this:
> {code}
> fun foo.Bar.baz() { x ->
> // ...
> }
> {code}
> For any new users or just to add something quickly that can be used in a
> file, I think I'm looking for an enhancement to "import static ..." that will
> get substituted in the source unit, like {{StaticImportVisitor}} does today
> for static method calls. For example:
> {code:groovy}
> import static foo.Bar.baz
> import static /*something*/ foo.Bar.baz
> baz("") // supported by first import
> "".baz() // supported by second import
> {code}
> I have been considering whether "extension", "default", some annotation or
> something else should be used for /\*something\*/ in the script above.
> Similar to Kotlin, this could let someone declare an extension in a single
> script with no dynamic runtime impact:
> {code:groovy}
> import static /*something*/ ThisScript.*
> static ext(String self) {
> print self
> }
> "works".ext()
> {code}
> Has anyone looked at something like this in Groovy or other languages and has
> some feedback?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11143) Add extension method to source unit (same locality as static import)
[
https://issues.apache.org/jira/browse/GROOVY-11143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749981#comment-17749981
]
Jochen Theodorou commented on GROOVY-11143:
---
[~emilles] "I've seen "import static extension foo.Bar.baz;" for some language.
(citation required)" was that maybe XText?
I did have a look at this before the Pivotal incident. I think it works easily
(there are many details to work out) in the static compiler, but in
non-static... I had the idea of meta class realms for this, but no time to
implement or really develop it in enough detail.
> Add extension method to source unit (same locality as static import)
>
>
> Key: GROOVY-11143
> URL: https://issues.apache.org/jira/browse/GROOVY-11143
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Eric Milles
>Priority: Major
>
> I have been poking around with the many ways to extend a class/object's
> functionality within groovy. To add a new method that can be called like any
> other instance method, there are a few possibilities:
> 1. modify the MetaClass
> {code:groovy}
> String.metaClass.ext = { ->
> print delegate
> }
> "works".ext()
> {code}
> 2. use a category class
> {code:groovy}
> @Category(String) class Cat {
> void ext() {
> println this
> }
> }
> use (Cat) {
> "works".ext()
> }
> {code}
> 3. apply a mixin
> first create class similar to Cat in (2)
> {code:groovy}
> def str = "works"; str.metaClass.mixin(Cat)
> str.ext()
> {code}
> 4. apply a trait
> {code:groovy}
> trait Ext {
> void ext() { println this.toLowerCase() } // see GROOVY-11142
> }
> "works".withTraits(Ext).ext()
> {code}
> 5. create an extension moodule
> - create class similar to Cat in (2)
> - create META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule file
> - build and deploy separately from current script / project
> What I'm after is something that works as easily in a script or source file
> as static imports but lets me call like an extension method. And does not
> modify state outside of the current script (like {{MetaClass}}) or introduce
> a thread barrier (like {{use}}). And works with static type checking.
> Scala has an "extension" mechanism that is similar to static import but there
> is a keyword on the category class that lets compiler know the method is used
> like any other instance method. Scala used to provide "implicit" methods --
> I've lost my familiarity with those.
> I've seen "import static extension foo.Bar.baz;" for some language.
> (citation required)
> And lastly, Kotlin provides a local extension like this:
> {code}
> fun foo.Bar.baz() { x ->
> // ...
> }
> {code}
> For any new users or just to add something quickly that can be used in a
> file, I think I'm looking for an enhancement to "import static ..." that will
> get substituted in the source unit, like {{StaticImportVisitor}} does today
> for static method calls. For example:
> {code:groovy}
> import static foo.Bar.baz
> import static /*something*/ foo.Bar.baz
> baz("") // supported by first import
> "".baz() // supported by second import
> {code}
> I have been considering whether "extension", "default", some annotation or
> something else should be used for /\*something\*/ in the script above.
> Similar to Kotlin, this could let someone declare an extension in a single
> script with no dynamic runtime impact:
> {code:groovy}
> import static /*something*/ ThisScript.*
> static ext(String self) {
> print self
> }
> "works".ext()
> {code}
> Has anyone looked at something like this in Groovy or other languages and has
> some feedback?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747119#comment-17747119
]
Jochen Theodorou commented on GROOVY-10931:
---
[~emilles]If a method is not accessible and cannot be made accessible, then it
should not be part of the method selection. In the case here we are talking
about the same module. Assuming it is the unnamed module then
"--add-opens=java.base/java.lang.reflect=ALL-UNNAMED" should for example allow
all cases here.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking, invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745920#comment-17745920
]
Jochen Theodorou commented on GROOVY-11126:
---
[~emilles] But the code in that method imho expects the args[0] to be the
original receiver.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.14
>
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745918#comment-17745918
]
Jochen Theodorou commented on GROOVY-10931:
---
[~daniel_sun] what do you mean by "transforming methods for Java members"?
Bytecode-transformation?
What the lookup system does not provide is a general way to query a class for
its members. there are unreflect methods for this instead and they are using
the old reflection objects. but by getting them you may get those warnings
already... for example when we built the meta class method index. What
MethodHandles can handle is if you know the exact signature. In case of a
constructor method foo(String):void for example will not be found if you look
for foo(Object):void. Even looking for foo(String):Object would not work.
This means $getLookup is there to be able to unreflect a reflective object,
bypassing security limitations otherwise imposed. And it works only on classes
written in Groovy at the moment.
The feature exists mainly for testing, though testing with full modules system
as in "production" is something I have yet to see. Let us not forget that this
is not only about some private methods. The module system also prevents access
to public methods if not exported. If you want to test those you need to
bypass the restrictions. That means allowing module access on the command line
and exporting or compiling the test and the code into the same module. What
people did tend to do in testing pre JPMS is making a method protected so it
can be tested by a test in the same package. That does not work if the test and
the code are in different modules because of "split packages".
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10801) AST transform for simple utility classes (only static fields and methods)
[
https://issues.apache.org/jira/browse/GROOVY-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745557#comment-17745557
]
Jochen Theodorou commented on GROOVY-10801:
---
Remind me of https://projectlombok.org/features/experimental/UtilityClass
> AST transform for simple utility classes (only static fields and methods)
> -
>
> Key: GROOVY-10801
> URL: https://issues.apache.org/jira/browse/GROOVY-10801
> Project: Groovy
> Issue Type: New Feature
> Components: ast builder
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
>
> Similar to the {{@Category}} transform, I'd like to have a local transform
> for utility classes. Consider the following:
> {code:groovy}
> @Namespace
> class C {
> int constant = 1
> def method() {
> // ...
> }
> }
> {code}
> This would be Groovy shorthand for the canonical "utility class":
> {code:groovy}
> final class C {
> private C() { throw new AssertionError() }
> public static final int constant = 1
> static method {
> // ...
> }
> }
> {code}
> *Update:* Like {{trait}} or {{record}}, we might consider taking this to the
> next step:
> {code:groovy}
> namespace C {
> int constant = 1
> def method() {
> // ...
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745553#comment-17745553
]
Jochen Theodorou commented on GROOVY-11126:
---
[~emilles] So if you use def test(string) your newly added block will still be
visited? then I misunderstood something in the code. The diff is not always
ideal for such things.
[~kenwdelong]You still have the version with the environment variable set
running? And the problem did not appear again?
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.14
>
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745127#comment-17745127
]
Jochen Theodorou edited comment on GROOVY-11126 at 7/20/23 3:18 PM:
[~emilles]I think that needs a bit rework. First of all I would change the test
to not do the times loop, it is not required for the issue, and if it is, then
the there is another problem hidden by your solution. So I suggest using:
{code:Java}
def test(String string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code}
that is especially to cover the case NotNull->Null and Null->NotNull.
New line 943 does the null case, and applies guards IS_NULL and optionally
SAME_CLASS. 964 is the elseif to that, so here the receiver is not null. It
adds here the SAME_CLASS check if the arguments can change class. Your new code
in 970 is then another elseif and only called if the receiver is not null and
the arguments cannnot change class. Which means it will not be added in the
following case:
{code:Java}
def test(string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code}
Therefore your if-block should be inside the first elseif.
Unless I did misread the code again of course.
was (Author: blackdrag):
[~emilles]I think that needs a bit rework. First of all I would change the test
to not do the times loop, it is not required for the issue, and if it is, then
the there is another problem hidden by your solution. So I suggest using:
{code:Java}
def test(String string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code:Java}
that is especially to cover the case NotNull->Null and Null->NotNull.
New line 943 does the null case, and applies guards IS_NULL and optionally
SAME_CLASS. 964 is the elseif to that, so here the receiver is not null. It
adds here the SAME_CLASS check if the arguments can change class. Your new code
in 970 is then another elseif and only called if the receiver is not null and
the arguments cannnot change class. Which means it will not be added in the
following case:
{code:Java}
def test(string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code:Java}
Therefore your if-block should be inside the first elseif.
Unless I did misread the code again of course.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.14
>
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745127#comment-17745127
]
Jochen Theodorou commented on GROOVY-11126:
---
[~emilles]I think that needs a bit rework. First of all I would change the test
to not do the times loop, it is not required for the issue, and if it is, then
the there is another problem hidden by your solution. So I suggest using:
{code:Java}
def test(String string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code:Java}
that is especially to cover the case NotNull->Null and Null->NotNull.
New line 943 does the null case, and applies guards IS_NULL and optionally
SAME_CLASS. 964 is the elseif to that, so here the receiver is not null. It
adds here the SAME_CLASS check if the arguments can change class. Your new code
in 970 is then another elseif and only called if the receiver is not null and
the arguments cannnot change class. Which means it will not be added in the
following case:
{code:Java}
def test(string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code:Java}
Therefore your if-block should be inside the first elseif.
Unless I did misread the code again of course.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.14
>
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745059#comment-17745059
]
Jochen Theodorou commented on GROOVY-11126:
---
[~emilles]Those dgm methods are just basically proxies for calls to methods in
DefaultGroovyMethods and such. They exist only for groovy itself. And have no
logic for safe navigation. I wonder if we really still need those actually.
They had their use in the old callsite caching, but in Groovy 4? Anyway, it is
very good you found an example!
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744972#comment-17744972
]
Jochen Theodorou commented on GROOVY-11126:
---
[~daniel_sun]it is not a spread call, it is a safeNavigation call. For me
things point to the caching, but why exactly no idea. I could imagine that
there is a point where the SoftReference is cleared or the cache emptied. And
then somehow the safe navigation flag is lost I have found no pointers in
the code that would back this though. I guess we would need to experiment where
we manually clear the cache or the reference to try to reproduce the problem.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744302#comment-17744302
]
Jochen Theodorou commented on GROOVY-11126:
---
ok, looks like safe navigation is now handled in the invokedynamic part. Since
this works in the beginning I assume that something changes over time. Best
candidate for this is imho the cache we use. To verify this would it be
possible for you to set the system property groovy.indy.callsite.cache.size to
0? My expectation is that then the error will either not happen or a lot
earlier.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-11126:
--
Description:
I have a server-side app that works perfectly for a long time (18-24h) then
suddenly starts throwing "impossible" errors.
{code:java}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.lang.CharSequence.length()" because "self" is null
at
org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
at
com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
{code}
The line of code at ColorParser:74 is:
{code:java}
int size = color?.size() ?: 0 {code}
The variable `color` is a String. The null-safe dereference operator has ceased
to short-circuit.
This code is years old and has run flawlessly. Since the upgrade from Spring
Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
NullPointerExceptions. This is happening at a couple of other places in the
code, all on null-safe dereferences that don't short-circuit. The above code is
hit 9,000+ times/day. We have a cluster of servers and they seem to develop the
problem within a couple hours of each other.
The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
3.9.1)
I have tried to reproduce the error by running a tiny program that mimics the
error, but so far after running 1.4 million invocations over 24h with no errors
(as you might expect).
was:
I have a server-side app that works perfectly for a long time (18-24h) then
suddenly starts throwing "impossible" errors.
{code:java}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.lang.CharSequence.length()" because "self" is null at
org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source) at
com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74) at
com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)at
com.hatchbaby.domain.Content.getRed(Content.groovy:173)
{code}
The line of code at ColorParser:74 is:
{code:java}
int size = color?.size() ?: 0 {code}
The variable `color` is a String. The null-safe dereference operator has ceased
to short-circuit.
This code is years old and has run flawlessly. Since the upgrade from Spring
Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
NullPointerExceptions. This is happening at a couple of other places in the
code, all on null-safe dereferences that don't short-circuit. The above code is
hit 9,000+ times/day. We have a cluster of servers and they seem to develop the
problem within a couple hours of each other.
The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
3.9.1)
I have tried to reproduce the error by running a tiny program that mimics the
error, but so far after running 1.4 million invocations over 24h with no errors
(as you might expect).
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743982#comment-17743982
]
Jochen Theodorou commented on GROOVY-11126:
---
Quite surprisingly this is not giving me the expected result. The javap output
does not contain the method, even though I see calls to it there... ah wait, I
may have forgotten a flag to javap. I assume the method is private therefore it
needs to be "javap -p -v" on the class. Could you attach the output of that?
Sorry for the inconvenience.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source) at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)at
> com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743511#comment-17743511
]
Jochen Theodorou commented on GROOVY-11126:
---
[~kenwdelong] This is very odd. The trace does not help so much because then it
is already too late. Would it be possible for you to attach the compiled
ColorParser class? It would be enough to run "javap -v" on the class and attach
that output or only attach the print out for the code of the method. I am
asking because I am wondering if the version you compile Groovy with is really
the Spring Boot version. And since the Null-safe dereference is almost
completely bytecode I would like to be sure I look at the right output.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source) at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)at
> com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
