improve decompilation experience #418
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Commits best reviewed in isolation. I'm not sure about the last commit, actually. It imposes an artificial restriction on generating lambdas so that the behavior is consistent between the default and debug mode. I tried to find a way to allow defining parameters before captures in the debug mode, but failed, and this extra restriction isn't terribly bad, so I felt I'll just submit this and see what you think. |
02131c5 to
694c3a8
Compare
This is to workaround the IntelliJ IDEA decompiler (FernFlower) deficiency where it ignores all synthetic members of decompiled classes. Since we used to mark all members as synthetic, a decompiled class would be just empty, which is certainly not good. We still mark the generated classes/interfaces as synthetic, which should be good enough of a marker to everyone that all members are also synthetic.
This is in inticipation of another change: in the debugging mode, we'll generate lambdas that use the classic `LambdaMetafactory` translation strategy instead of our custom one. Our custom strategy cannot pass through decompilation, which is not good.
694c3a8 to
8169f98
Compare
dmlloyd
reviewed
Jun 23, 2025
Previously, the counter was present in `BlockCreatorImpl` and so was unique for each block. This is not necessarily correct; it is possible for one method to have multiple blocks and each of those blocks to generate an anonymous class. With this commit, the counter is present in `TypeCreatorImpl` and so is unique to each generated type. This is always correct.
This is (likely) slower and bigger than our custom translation strategy, but is supported by decompilers (at least by FernFlower), so it should be used in the debug mode. The following limitations exist: - serializable lambdas are not supported yet (but they are not supported by our custom translation strategy either) - captures must be defined first, before parameters
This is to unify the behavior in the standard ("release") mode and debug mode
when it comes to lambdas. Our custom translation strategy doesn't care about
ordering between defining captures and parameters, but the standard one (based
on `LambdaMetafactory`) does, so this restriction brings them both on par.
8169f98 to
93b6e3a
Compare
dmlloyd
approved these changes
Jun 23, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #416