Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix bug where origins of synthetic method calls override each other #957

Merged

Conversation

codecholeric
Copy link
Collaborator

Calls to lambda methods lambda$abc$123 seem to have unique origins with current JDK versions. I.e. even two identical consecutive lambda invocations will lead to two separate synthetic methods. Unfortunately, this is not the case for synthetic access$123 methods (to circumvent private modifiers), which lead to a bug where multiple origins of such a call would override each other.
This lead e.g. to the behavior in #923, where the application of AspectJ introduced an access$123 method that was called from multiple places. But, only one such call would randomly be created during the import, which lead to an unpredictable behavior of which cycles between outer and inner classes would be detected.
We now record multiple access records for any synthetic call and trace back all those records instead of just the last one. This way all such synthetic accesses should be imported correctly now.

Signed-off-by: Peter Gafert peter.gafert@tngtech.com

Calls to lambda methods `lambda$abc$123` seem to have unique origins with current JDK versions. I.e. even two identical consecutive lambda invocations will lead to two separate synthetic methods. Unfortunately, this is not the case for synthetic `access$123` methods (to circumvent private modifiers), which lead to a bug where multiple origins of such a call would override each other.
This lead e.g. to the behavior in #923, where the application of AspectJ introduced an `access$123` method that was called from multiple places. But, only one such call would randomly be created during the import, which lead to an unpredictable behavior of which cycles between outer and inner classes would be detected.
We now record multiple access records for any synthetic call and trace back all those records instead of just the last one. This way all such synthetic accesses should be imported correctly now.

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
Copy link
Member

@hankem hankem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@codecholeric codecholeric merged commit 0f54ef8 into main Sep 17, 2022
@codecholeric codecholeric deleted the fix-synthetic-access-methods-accessed-from-multiple-origins branch September 17, 2022 17:37
snuyanzin added a commit to snuyanzin/flink that referenced this pull request Nov 7, 2022
snuyanzin added a commit to snuyanzin/flink that referenced this pull request Dec 11, 2022
snuyanzin added a commit to snuyanzin/flink that referenced this pull request Dec 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants