JDT special code

[jukzi]

The general purpose JDT contains Code that behaves different for certain package names, see for example org.eclipse.jdt.internal.compiler.lookup.TypeConstants.ITYPEBINDING emitting an Error "The uninterned types {0} and {1} should not be compared using ==/!= operators." only on that certain package. See org.eclipse.jdt.core.tests.compiler.regression.ProgrammingProblemsTest.test0060()
Is that reasonable?

[stephan-herrmann]

Is that reasonable?

Why not?

We actually have at least two different categories in this area:

1. We implemented many requests that static analysis should "know" about the meaning and pitfalls of various types and methods out there. Be it to report "unlikely-argument" for methods like equals(Object) or contains(Object), or to leverage known semantics in null analysis (of general purpose methods, of injection annotations ...), resource analysis what not.
2. Additionally we used the super powers of the sophisticated machine called "ecj" to safe-guard a fundamental design change we had to make when Java 8 forced us to abandon reference comparison for TypeBindings except for well understood and documented exceptions.

What you are asking about is category (2). This implementation has created significant benefit for our own implementation, so we could just be happy it's there and will protect us during future code changes. Alternatively, we could discuss two questions:

• Is this self-referential analysis causing any harm (regarding complexity, performance)? If so, would it make sense to guard these additional checks by a flag SELF_COMPILING_ECJ (thus adding further complexit)? Or is the harm sufficient to motivate removal of the code, in which case we need to be very extra-careful not to introduce bugs of the kind which the analysis detects?
• Or is the strange aspect of this only that the analysis is only self-referential? Do clients have use cases where they would like to extend this analysis to other types of their own domain, where raising warnings on == or != would be equally helpful?

[stephan-herrmann]

• Do clients have use cases where they would like to extend this analysis to other types of their own domain, where raising warnings on == or != would be equally helpful?

• See also feat: issue optional warning using '==' for wrapper types #2188