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

Rewrite DiamondOperatorCheck in Spoon #559

Open
Luro02 opened this issue Jul 2, 2024 · 0 comments
Open

Rewrite DiamondOperatorCheck in Spoon #559

Luro02 opened this issue Jul 2, 2024 · 0 comments
Labels
D-hard low-priority pmd unresolved Some decisions have not been made yet or it is not obvious what should be detected.

Comments

@Luro02
Copy link
Collaborator

Luro02 commented Jul 2, 2024

Description

What it does?

For generic calls one can explicitly add the type like this new ArrayList<String>(). In many cases explicitly writing the type is redundant, because the compiler can infer it.

Current implementation

The implementation is currently done in PMD, but this has several problems:

  • the PMD dependency can not be removed
  • the submission has to be compiled for spoon and PMD
  • any bugs might take a long time to be fixed

PMD implements the check by checking each invocation and creating a new one, but with the explicit type removed. If the new invocation works, the type is redundant.

How to implement this in Spoon?

The problem is that spoon does not expose any of the type inference done by jdt and every constructed invocation must set the type manually.

There are some solutions that come to mind to replicate a similar behavior:

  1. Implement type inference according to the JLS (note: not worth the amount of work and error prone)
  2. Try to work with the spoon developers to expose the jdt type inference and apply them to created elements
  3. Replicate the relevant source code in a new project and recompile it to check if it still works with the type removed. The proof of concept would be very easy to implement, but it would result in a compilation of the model for every diamond operator with an explicit type. The compilation of the model is the part that takes by far the longest time. To mitigate this, one could try to minimize the source code as much as possible, before recompiling or one could remove all diamond operators at once, and then try to map the compiler messages to the relevant source fragments (in that case the project has to be recompiled only once).
@Luro02 Luro02 added pmd D-hard low-priority unresolved Some decisions have not been made yet or it is not obvious what should be detected. labels Jul 2, 2024
@Luro02 Luro02 mentioned this issue Jul 2, 2024
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D-hard low-priority pmd unresolved Some decisions have not been made yet or it is not obvious what should be detected.
Projects
None yet
Development

No branches or pull requests

1 participant