1. Helper Methods for Specific Visitors

- Methods like `makeNewClass` and `makeBinary` which brings a dependency like `Operators` should not be part of every visitor. Instead, these could be abstracted into specific subclasses of visitors where these operations are relevant.
- This approach would reduce unnecessary duplications and maintain cleaner separation of concerns.

2. Tracking `currentMethodSymbol`

- In certain passes after `Attr`, scoping information is discarded, but tracking of the `currentMethodSymbol` is needed (and synthesis of one in case of traversals of blocks, etc)
- A possible solution is to move this functionality into a backend visitor superclass that maintains this context for later passes. This would ensure that necessary information is retained and accessible in later stages of processing.

3. Variable Index Tracking

- This is similar to a variable number index like `variableIndex` which is related to handling local temp variables.
- Centralizing this tracking mechanism might also benefit from 2) above, making it easier to manage in later transformations or passes.

4. `indyCalls` Preparation Methods Consolidation

- `indyCalls` seem to be increasingly common, and the setup for these calls (with parameters like `actualParams`, `staticArgs`, `staticArgsValues`, etc.) appears to be duplicated in multiple places.
- We can consolidate this setup inso shared code that prepares the `indyCall` in one place, reducing redundancy. A helper method or utility class for `indyCall` preparation might ensure consistency and simplify maintenance.

5. Assess whether checks that decide whether a pipeline step is needed or not are really required. Skipping a translation step (e.g. for lambdas) might be advantageous for performance. If this is not the case, this logic can be removed to simplify the pipeline process (https://bugs.openjdk.org/browse/JDK-8345474)