[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=17747148#comment-17747148
]
Eric Milles edited comment on GROOVY-10931 at 7/25/23 10:54 PM:
Okay, I see what I did -- "sender" was passed to {{transformMetaMethod}}. Now
it's just:
{code:groovy}
List list = [1, 2, 3]
assert list.size == 3 // "size" is private
String string = ""
assert string.properties // "value" is private -- resolved
{code}
was (Author: emilles):
Okay, I see what I did -- "sender" was passed to {{transformMetaMethod}}. Now
it's just:
{code:groovy}
List list = [1, 2, 3]
assert list.size == 3 // "size" is private
String string = ""
assert string.properties // "value" is private
{code}
> 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] [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=17745704#comment-17745704
]
Eric Milles edited comment on GROOVY-10931 at 7/25/23 10:54 PM:
https://github.com/apache/groovy/commit/d465bec90ebec87928a79575388df1d2ca46c530
https://github.com/apache/groovy/commit/b56ab4f7d2d42c4377fe3fccf791a4d7edf24e1e
https://github.com/apache/groovy/commit/79dfdd03eaf6aaf30e667748dd2610e7f4b575eb
https://github.com/apache/groovy/commit/bff4797be7b17010885342c5c74eb03635ca4a21
https://github.com/apache/groovy/commit/a447655c21d8b574b495ea9bf964ba2621d02862
https://github.com/apache/groovy/commit/dce378e1e242f551eb697a30f6aca5a9f6188e26
was (Author: emilles):
https://github.com/apache/groovy/commit/d465bec90ebec87928a79575388df1d2ca46c530
https://github.com/apache/groovy/commit/b56ab4f7d2d42c4377fe3fccf791a4d7edf24e1e
https://github.com/apache/groovy/commit/79dfdd03eaf6aaf30e667748dd2610e7f4b575eb
https://github.com/apache/groovy/commit/bff4797be7b17010885342c5c74eb03635ca4a21
https://github.com/apache/groovy/commit/a447655c21d8b574b495ea9bf964ba2621d02862
> 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] [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=17745704#comment-17745704
]
Eric Milles edited comment on GROOVY-10931 at 7/25/23 8:25 PM:
---
https://github.com/apache/groovy/commit/d465bec90ebec87928a79575388df1d2ca46c530
https://github.com/apache/groovy/commit/b56ab4f7d2d42c4377fe3fccf791a4d7edf24e1e
https://github.com/apache/groovy/commit/79dfdd03eaf6aaf30e667748dd2610e7f4b575eb
https://github.com/apache/groovy/commit/bff4797be7b17010885342c5c74eb03635ca4a21
https://github.com/apache/groovy/commit/a447655c21d8b574b495ea9bf964ba2621d02862
was (Author: emilles):
https://github.com/apache/groovy/commit/d465bec90ebec87928a79575388df1d2ca46c530
https://github.com/apache/groovy/commit/b56ab4f7d2d42c4377fe3fccf791a4d7edf24e1e
https://github.com/apache/groovy/commit/79dfdd03eaf6aaf30e667748dd2610e7f4b575eb
https://github.com/apache/groovy/commit/bff4797be7b17010885342c5c74eb03635ca4a21
> 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] [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=17747100#comment-17747100
]
Eric Milles edited comment on GROOVY-10931 at 7/25/23 7:01 PM:
---
[~daniel_sun] [~blackdrag] [~paulk] I was looking over the remaining illegal
access warnings in the master branch Java 11 build. I'm trying to understand
the {{EnumMap#equals}} test case. This is item #5 in GROOVY-9081. Surely if I
have "enumMap1 == enumMap2" that should go through the public {{equals}}
method. I do see that if "private equals(EnumMap)" is not selected, then the
extension method "equals(Map,Map)" is used instead. Is this part of the
motivation? Is the expectation that if an inaccessible overload is chosen that
there should not be an illegal access warning?
Update: Groovy 3 switches from "equals(EnumMap)" to "equals(Object)" as part of
the {{transformMetaMethod}} call. I'm checking if Groovy 4 does this and why
Groovy 5 seems different.
was (Author: emilles):
[~daniel_sun] [~blackdrag] [~paulk] I was looking over the remaining illegal
access warnings in the master branch Java 11 build. I'm trying to understand
the {{EnumMap#equals}} test case. This is item #5 in GROOVY-9081. Surely if I
have "enumMap1 == enumMap2" that should go through the public {{equals}}
method. I do see that if "private equals(EnumMap)" is not selected, then the
extension method "equals(Map,Map)" is used instead. Is this part of the
motivation? Is the expectation that if an inaccessible overload is chosen that
there should not be an illegal access warning?
> 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] [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=17747109#comment-17747109
]
Eric Milles edited comment on GROOVY-10931 at 7/25/23 6:46 PM:
---
Here are the four test cases from {{IllegalAccessTests}} that produce an access
warning. My understanding of them is that they represent truly illegal access.
{code:groovy}
import static org.codehaus.groovy.runtime.InvokerHelper.*
class Dolly {
String name
}
def dolly = new Dolly(name: "The Sheep")
invokeMethod(dolly, 'clone', EMPTY_ARGS) // forced call to Object#clone
String str = ''
assert str.properties // "value" is private
def items = [1, 2, 3]
assert items.size == 3 // "size" is private
def em1 = new EnumMap(RetentionPolicy)
def em2 = new EnumMap(RetentionPolicy)
assert em1 == em2 // EnumMap#equals(EnumMap) is private
{code}
was (Author: emilles):
Here are the four test cases from {{IllegalAccessTests}} that produce an access
warning. My understanding of them is that they represent truly illegal access.
{code:grrovy}
import static org.codehaus.groovy.runtime.InvokerHelper.*
class Dolly {
String name
}
def dolly = new Dolly(name: "The Sheep")
invokeMethod(dolly, 'clone', EMPTY_ARGS) // forced call to Object#clone
String str = ''
assert str.properties // "value" is private
def items = [1, 2, 3]
assert items.size == 3 // "size" is private
def em1 = new EnumMap(RetentionPolicy)
def em2 = new EnumMap(RetentionPolicy)
assert em1 == em2 // EnumMap#equals(EnumMap) is private
{code}
> 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] [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=17745704#comment-17745704
]
Eric Milles edited comment on GROOVY-10931 at 7/24/23 10:00 PM:
https://github.com/apache/groovy/commit/d465bec90ebec87928a79575388df1d2ca46c530
https://github.com/apache/groovy/commit/b56ab4f7d2d42c4377fe3fccf791a4d7edf24e1e
https://github.com/apache/groovy/commit/79dfdd03eaf6aaf30e667748dd2610e7f4b575eb
https://github.com/apache/groovy/commit/bff4797be7b17010885342c5c74eb03635ca4a21
was (Author: emilles):
https://github.com/apache/groovy/commit/d465bec90ebec87928a79575388df1d2ca46c530
https://github.com/apache/groovy/commit/b56ab4f7d2d42c4377fe3fccf791a4d7edf24e1e
https://github.com/apache/groovy/commit/79dfdd03eaf6aaf30e667748dd2610e7f4b575eb
> 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=17745704#comment-17745704
]
Eric Milles edited comment on GROOVY-10931 at 7/24/23 5:23 PM:
---
https://github.com/apache/groovy/commit/d465bec90ebec87928a79575388df1d2ca46c530
https://github.com/apache/groovy/commit/b56ab4f7d2d42c4377fe3fccf791a4d7edf24e1e
https://github.com/apache/groovy/commit/79dfdd03eaf6aaf30e667748dd2610e7f4b575eb
was (Author: emilles):
https://github.com/apache/groovy/commit/d465bec90ebec87928a79575388df1d2ca46c530
https://github.com/apache/groovy/commit/b56ab4f7d2d42c4377fe3fccf791a4d7edf24e1e
> 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=17746003#comment-17746003
]
Eric Milles edited comment on GROOVY-10931 at 7/23/23 1:55 AM:
---
Yes that’s the 9596 that I’m looking at next.
was (Author: emilles):
Yes that’s the 9586 that I’m looking at next.
> 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=17745704#comment-17745704
]
Eric Milles edited comment on GROOVY-10931 at 7/23/23 12:16 AM:
https://github.com/apache/groovy/commit/d465bec90ebec87928a79575388df1d2ca46c530
https://github.com/apache/groovy/commit/b56ab4f7d2d42c4377fe3fccf791a4d7edf24e1e
was (Author: emilles):
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] [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=17745928#comment-17745928
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 12:04 PM:
---
Hi Jochen,
Here is the code for transform method, i.e. to find visible method in the
type tree.
[https://github.com/apache/groovy/blob/244886a6da837afe3ab39b318c32e5f8765e99cc/src/main/java/org/codehaus/groovy/vmplugin/v9/Java9.java#L234]
$getLookup method of each Groovy class can just help us to access all
members of the Groovy class with the $getLookup method.
If the Groovy class is declared in a JPMS module and not be exported, the
$getLookup methods outside the module will not work either.
As we can see, $getLookup is just trying to keep compatibility for
reflection as possible as it could.
was (Author: daniel_sun):
Hi Jochen,
Here is the code for transform method, i.e. to find visible method in the
type tree.
[https://github.com/apache/groovy/blob/244886a6da837afe3ab39b318c32e5f8765e99cc/src/main/java/org/codehaus/groovy/vmplugin/v9/Java9.java#L234]
$getLookup method of each Groovy class can just help us to access all
members of the Groovy class with the $getLookup method.
If the Groovy class is declared in a JPMS module and not be exported,
$getLookup will not work either.
As we can see, $getLookup is just trying to keep compatibility for
reflection as possible as it could.
> 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=17745869#comment-17745869
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 7:24 AM:
--
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 and continue support accessing
invisible members, even if JDK 9+ breaks the compatibility... The solution
applied by Groovy 4 is add $getLookup method to each Groovy class, the method
can help us access all members of the Groovy class without any warnings.
To sum up, we really care about the illegal access warnings.
was (Author: daniel_sun):
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 and continue support accessing
invisible members, 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] [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=17745869#comment-17745869
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 7:22 AM:
--
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 and continue support accessing
invisible members, even if JDK 9+ breaks the compatibility...
To sum up, we really care about the illegal access warnings.
was (Author: daniel_sun):
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] [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 7:21 AM:
--
In order to avoid the warnings, 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 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.
> 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: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)
