[jira] [Comment Edited] (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=17745870#comment-17745870
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 4:20 AM:
--
We have to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not be avoided as you could find in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
was (Author: daniel_sun):
We have to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not avoided as you found in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
> 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] [Comment Edited] (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=17745870#comment-17745870
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 4:17 AM:
--
We have to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not avoided as you found in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
was (Author: daniel_sun):
We find to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not avoided as you found in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
> 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-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745870#comment-17745870
]
Daniel Sun commented on GROOVY-10931:
-
We find to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not avoided as you found in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
> 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-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745869#comment-17745869
]
Daniel Sun commented on GROOVY-10931:
-
As Groovy allows illegal reflection since it borned, Groovy users benefit from
the feature in their projects especially useful when testing internals.
The illegal reflective warnings appear since JDK 9, which introduces the JPMS.
The warnings are very annoying and drive Groovy users crazy... so we tried our
best to keep the compatibility, i.e. no warnings, even if JDK 9+ breaks the
compatibility...
To sum up, we really care about the illegal access warnings.
> 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-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745865#comment-17745865
]
Eric Milles commented on GROOVY-10931:
--
Thanks for looking over the changes. I do plan to refine it. I just needed it
to get out there to see where the gaps are.
> 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-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745863#comment-17745863
]
Eric Milles commented on GROOVY-10931:
--
Also, if there are warnings on JDK below 16, are we really concerned?
Everything runs on jdk16+ which is where the access removal starts.
> 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-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745861#comment-17745861
]
Eric Milles commented on GROOVY-10931:
--
Is there a way to convert this into some kind of test? I’m not sure how it is
still giving a warning when it is running the lookup code (minus the
self-provided lookup).
> 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-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745857#comment-17745857
]
Daniel Sun commented on GROOVY-10931:
-
Hi Eric,
$getLookup implementation can handle all JDKs by the same way, but it has
its own flaw as you found, so I am very happy to see the improvement, but I do
not understand how the improvement help us avoid the illegal reflective
warnings under pre-16 JDKs, so I went to check the output of test build for
JDK11 and found some warnings, could you tweak the improvement further more?
https://github.com/apache/groovy/actions/runs/5625969498/job/15245826217#step:6:309
> Task :groovy-datetime:testClasses
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v9.Java9
(file:/home/runner/work/groovy/groovy/build/libs/groovy-raw-5.0.0-SNAPSHOT.jar)
to method sun.util.calendar.ZoneInfo.equals(java.lang.Object)
> 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] [Updated] (GROOVY-11131) Bump javaparser to 3.25.4
[ https://issues.apache.org/jira/browse/GROOVY-11131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11131: --- Fix Version/s: 3.0.19 > Bump javaparser to 3.25.4 > - > > Key: GROOVY-11131 > URL: https://issues.apache.org/jira/browse/GROOVY-11131 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.14, 3.0.19 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11131) Bump javaparser to 3.25.4
[ https://issues.apache.org/jira/browse/GROOVY-11131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11131. Resolution: Fixed > Bump javaparser to 3.25.4 > - > > Key: GROOVY-11131 > URL: https://issues.apache.org/jira/browse/GROOVY-11131 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.14, 3.0.19 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11132) Bump jqwik to 1.7.4 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11132. Fix Version/s: 4.0.14 (was: 4.0.8) Resolution: Fixed > Bump jqwik to 1.7.4 (test dependency) > - > > Key: GROOVY-11132 > URL: https://issues.apache.org/jira/browse/GROOVY-11132 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.14 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11127) Add '|', '&', and '^' operators to Set and SortedSet
[
https://issues.apache.org/jira/browse/GROOVY-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745835#comment-17745835
]
ASF GitHub Bot commented on GROOVY-11127:
-
paulk-asert commented on PR #1915:
URL: https://github.com/apache/groovy/pull/1915#issuecomment-1646295812
@merscwog Sounds good to me.
> Add '|', '&', and '^' operators to Set and SortedSet
>
>
> Key: GROOVY-11127
> URL: https://issues.apache.org/jira/browse/GROOVY-11127
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Spencer Allain
>Assignee: Paul King
>Priority: Trivial
> Fix For: 5.x
>
>
> Many languages conventionally allow sets to use '|' as union, '&' as
> intersection, and '^' as symmetric difference operations on sets.
> This ticket is proposing adding these operations as DefaultGroovyMethods for
> Set and SortedSet such that the below tests should pass:
> {code:java}
> Set a = [1,2,3,4] as Set
> Set b = [3,4,5,6] as Set
> assert (a | b) == [1,2,3,4,5,6] as Set
> assert (a & b) == [3,4] as Set
> assert (a ^ b) == [1,2,5,6] as Set
> Set d = ['a', 'B', 'c'] as Set
> Set e = ['A', 'b', 'D'] as Set
> assert d.and(e, String.CASE_INSENSITIVE_ORDER) == ['a', 'B'] as Set
> assert d.and(e, Comparator.naturalOrder()) == [] as Set
> assert d.xor(e, String.CASE_INSENSITIVE_ORDER) == ['c', 'D'] as Set
> assert d.xor(e, Comparator.naturalOrder()) == ['a', 'B', 'c', 'A', 'b', 'D']
> as Set
> {code}
> A [Pull Request|https://github.com/apache/groovy/pull/1915] exists that
> implements the desired additions for the 5.x groovy branch (master), but it
> should be fairly easy to make the functionality available in 4.x if desired.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [groovy] paulk-asert commented on pull request #1915: GROOVY-11127: Set operator extension methods
paulk-asert commented on PR #1915: URL: https://github.com/apache/groovy/pull/1915#issuecomment-1646295812 @merscwog Sounds good to me. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17745833#comment-17745833
]
Eric Milles commented on GROOVY-11126:
--
[~blackdrag] I was referring to the path through MethodSelector#chooseMeta
> 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-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=17745832#comment-17745832
]
Eric Milles edited comment on GROOVY-10801 at 7/21/23 9:44 PM:
---
Reading the Lombok docs, I’m concerned about static import sopport as well. I
was thinking about moving StaticImportVisitor to the end of semantic analysis
or the start of canonicalization. I’ll try f do one things and report back.
was (Author: emilles):
Reading the Lombok docs, I’m concert about static import sopport as well. I was
thinking about moving StaticImportVisitor to the end of semantic analysis or
the start of canonicalization. I’ll try f do one things and report back.
> 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-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=17745832#comment-17745832
]
Eric Milles commented on GROOVY-10801:
--
Reading the Lombok docs, I’m concert about static import sopport as well. I was
thinking about moving StaticImportVisitor to the end of semantic analysis or
the start of canonicalization. I’ll try f do one things and report back.
> 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] [Resolved] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-10931.
--
Fix Version/s: 5.0.0-alpha-1
Resolution: Fixed
https://github.com/apache/groovy/commit/d465bec90ebec87928a79575388df1d2ca46c530
> 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] [Updated] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10931:
-
Affects Version/s: (was: 4.0.9)
> 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
>Affects Versions: 5.0.0-alpha-1
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
>
> 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] [Updated] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10931:
-
Language: groovy
> 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
>Affects Versions: 5.0.0-alpha-1, 4.0.9
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
>
> 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] [Updated] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10931:
-
Affects Version/s: (was: 5.0.0-alpha-1)
> 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
>
> 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=17745673#comment-17745673
]
Kenneth W DeLong commented on GROOVY-11126:
---
We let that run for about 36 hours with no errors, but we have since reverted
it due to the load on the servers (and due to what appears to be a fix!)
> 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-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=17745637#comment-17745637
]
Eric Milles commented on GROOVY-10801:
--
I did consider some alternate names before settling on `Namesapce`. I think
`StaticScope` (akin to `PackageScope`) is one of the better ones. I've also
been considering an implicit case where a file Foo.groovy only has methods and
field-like declarations it would be mapped to a script but instead "utility"
class, with all static members and private no-arg constructor. This may jive
or may conflict with your recent changes for alternative main method detection.
> 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-11127) Add '|', '&', and '^' operators to Set and SortedSet
[
https://issues.apache.org/jira/browse/GROOVY-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745595#comment-17745595
]
ASF GitHub Bot commented on GROOVY-11127:
-
merscwog commented on PR #1915:
URL: https://github.com/apache/groovy/pull/1915#issuecomment-1645571858
I'm sure this will not satisfy everyone, but what if I did:
- intersect() already exists, so tie that to '&' for all the same types
(alias essentially, although just for non-comparator, since the long-form alias
would always be available)
- create a union() operator for all types, and tie it to '|' for those same
types (very similar behavior to existing intersect() operator
> Add '|', '&', and '^' operators to Set and SortedSet
>
>
> Key: GROOVY-11127
> URL: https://issues.apache.org/jira/browse/GROOVY-11127
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Spencer Allain
>Assignee: Paul King
>Priority: Trivial
> Fix For: 5.x
>
>
> Many languages conventionally allow sets to use '|' as union, '&' as
> intersection, and '^' as symmetric difference operations on sets.
> This ticket is proposing adding these operations as DefaultGroovyMethods for
> Set and SortedSet such that the below tests should pass:
> {code:java}
> Set a = [1,2,3,4] as Set
> Set b = [3,4,5,6] as Set
> assert (a | b) == [1,2,3,4,5,6] as Set
> assert (a & b) == [3,4] as Set
> assert (a ^ b) == [1,2,5,6] as Set
> Set d = ['a', 'B', 'c'] as Set
> Set e = ['A', 'b', 'D'] as Set
> assert d.and(e, String.CASE_INSENSITIVE_ORDER) == ['a', 'B'] as Set
> assert d.and(e, Comparator.naturalOrder()) == [] as Set
> assert d.xor(e, String.CASE_INSENSITIVE_ORDER) == ['c', 'D'] as Set
> assert d.xor(e, Comparator.naturalOrder()) == ['a', 'B', 'c', 'A', 'b', 'D']
> as Set
> {code}
> A [Pull Request|https://github.com/apache/groovy/pull/1915] exists that
> implements the desired additions for the 5.x groovy branch (master), but it
> should be fairly easy to make the functionality available in 4.x if desired.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [groovy] merscwog commented on pull request #1915: GROOVY-11127: Set operator extension methods
merscwog commented on PR #1915: URL: https://github.com/apache/groovy/pull/1915#issuecomment-1645571858 I'm sure this will not satisfy everyone, but what if I did: - intersect() already exists, so tie that to '&' for all the same types (alias essentially, although just for non-comparator, since the long-form alias would always be available) - create a union() operator for all types, and tie it to '|' for those same types (very similar behavior to existing intersect() operator -- so it attempts to preserve original collection orders, but does not insert duplicates based upon the comparator into resulting collection) - create a symmetricDiff() operator for all types and tie it to '^' (using minus and union operators, although I believe with the two minuses all comparator-specific behavior for the union might be unnecessary and a simple plus could suffice -- I haven't 100% convinced myself this is true always, but I'm hoping that it is) - union(minus(a,b,comparator), minus(b,a,comparator), comparator) => plus(minus(a,b,comparator), minus(b,a,comparator)) aliased '&', '|', '^' would only be for the non-comparator variants of the operators. Or, I only have those convenience operators for Sets. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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] [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=17745514#comment-17745514
]
Paul King commented on GROOVY-10801:
I have no problem with the idea but I'm unsure of the name. What would you
think of the name `@Utility`?
For cases where you'd be willing to add @CompileStatic and @POJO, you could get
rid of the GroovyObject additions?
> 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)
