Community
Participate
Working Groups
"overloads" is a valid warning type for OpenJDK and Oracle JDK, as of Java 8, but it is not recognized by Eclipse JDT. The following valid warning suppression: @SuppressWarnings("overloads") results in Eclipse showing its own warning: Unsupported @SuppressWarnings("overloads") The whole point of suppressing the warning in the code is because the developer doesn't want to see it. Eclipse not recognizing the warning type and issuing its own "in lieu of" warning conflicts with the developer's intentions to suppress the warning during development. Omitting the warning from the code results in javac warning outputs about potentially ambiguous method names.
Does Eclipse show any other warning for that line? If not, it can perfectly deal with the overloads and just doesn't need any suppresswarnings there. The JDT compiler is known to analyze sources better than javac in some cases, thereby not even showing warnings that you may get with javac. If you want to use Eclipse "just as an editor, but with javac as backend", then I would recommend the workaround of disabling the warning for unknown suppresswarnings.
(In reply to Christopher Tubbs from comment #0) > Omitting the warning from the code results in javac warning outputs about > potentially ambiguous method names. This could be an interesting warning to add to JDT, but for that we'd need a clear definition of when exactly such warning is raised. Do you have a link to such definition / specification? While JLS recommends that implementations should coordinate the warnings raised and @SW tokens recognized, none of my efforts to coordinate with Oracle ever produced a result ...
(In reply to Michael Keppler from comment #1) > Does Eclipse show any other warning for that line? No. > If not, it can perfectly > deal with the overloads and just doesn't need any suppresswarnings there. That's possible, but isn't it also possible JDT isn't detecting a possible problem that `javac` is, because it's not analyzing for it in this case? I'm not an expert on the situation being analyzed... I'm only reporting from a user experience perspective. However, what little I do know about this particular warning suggests that Eclipse can't "deal with it". Taken from https://stackoverflow.com/a/29137665/196405 : """ The compiler is issuing warnings at the method declarations to indicate that the likely code a programmer would write to call one of these methods (as shown above) will result in a compile-time error. """ It's a warning about code that Eclipse may not have available to analyze (the calling code... which could exist in a separate code base, if this code is intended to be a library). > The JDT compiler is known to analyze sources better than javac in some > cases, thereby not even showing warnings that you may get with javac. It may do better than `javac` at analyzing the potential problem... but the user experience is that it does worse at analyzing the warning suppression line itself than `javac` does. However, I don't think it can do better in this case, because it would have to have *all* calling code... which isn't possible if this is a public API for a library, or similar. > If you want to use Eclipse "just as an editor, but with javac as backend", > then I would recommend the workaround of disabling the warning for unknown > suppresswarnings. That's not exactly my use case; my use case is primarily a desire for consistency between my preferred development environment (Eclipse) and my open source project's build system (Maven). Other project developers have their own preferred IDEs... mine happens to be Eclipse. It is also important to have consistency in the development environment and quality checks during CI (our project strives for zero-warnings in CI). The workaround could work... but for me personally, I'd rather just put up with the annoying Eclipse warning (the CI environment takes priority) until Eclipse stops issuing it.
(In reply to Stephan Herrmann from comment #2) > This could be an interesting warning to add to JDT, but for that we'd need a > clear definition of when exactly such warning is raised. Do you have a link > to such definition / specification? I don't have an link to the JLS, but from the StackOverflow explanation I linked previously (https://stackoverflow.com/a/29137665/196405), it looks like it should occur when an otherwise well-behaved functional interface has an overloaded method that would create ambiguity if a caller were to call it without specifying types (even if that calling code doesn't appear in the code being analyzed). The warning seems to be intended for API designers more than it is a warning for callers. For my use case, I would be satisfied if Eclipse simply recognized the warning type and provided a configuration option to ignore it when it appear in code, even if Eclipse doesn't implement any of its own analysis here.
(In reply to Christopher Tubbs from comment #4) > For my use case, I would be satisfied if Eclipse simply recognized the > warning type and provided a configuration option to ignore it when it appear > in code, even if Eclipse doesn't implement any of its own analysis here. I'd consider that a bit lame. I asked for more information in SO, let's see if it bears any fruit this time.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
(In reply to Stephan Herrmann from comment #5) > I asked for more information in SO, let's see if it bears any fruit this > time. After 2 years' time there's still no help from oracle. I asked again but I won't hold my breath on this. Without such help the best I can think of is: recognize the token "overloads" (is it plural indeed?) and instead of the normal *warning* raise an *info* stating that ecj cannot analyze whether or not that annotation is appropriate, because of undefined semantics. The same could be applied to other javac-only suppression tokens. Implementing such silly workaround looks like an appropriate task for a contributor new to compiler issues.
(In reply to Stephan Herrmann from comment #7) > Without such help the best I can think of is: recognize the token > "overloads" (is it plural indeed?) and instead of the normal *warning* raise Yes, it really is plural. See `javac --help-lint` on any standard build of OpenJDK for a complete list of supported -Xlint keys. Most recently, I did it on Fedora's OpenJDK 17 build, but it should be the same list from Eclipse Temurin builds. > an *info* stating that ecj cannot analyze whether or not that annotation is > appropriate, because of undefined semantics. The same could be applied to > other javac-only suppression tokens. This seems reasonable to me. > Implementing such silly workaround looks like an appropriate task for a > contributor new to compiler issues. It may be appropriate for a new contributor. I'm not really sure, because I'm not familiar at all with Eclipse code. It actually seems a bit complicated for a new contributor. Regardless, I wouldn't call this a "silly workaround". If Eclipse doesn't recognize a warning type that a programmer has suppressed, then it is one of two possibilities: 1) it's a spelling mistake (it is reasonable for Eclipse to warn for these), or 2) it's a warning type that Eclipse can't analyze, perhaps because it suppresses a warning supported by a different compiler I think Eclipse can support both these cases by treating them like a spelling dictionary. The "dictionary" can be pre-populated from the list of known warning types from any standard OpenJDK build (such as Eclipse Temurin) when running `javac --help-lint`. Anything on this list that Eclipse can't analyze can be placed in the dictionary by default, so that it produces an *info* message that it can't be analyzed. Users can add their own warning types to the dictionary. Any warning type found in use that is not in the dictionary should produce a warning in Eclipse that it's not recognized as a valid warning type, just like "overloads" does today. The user can decide for themselves whether they want Eclipse to ignore it with an *info* message, or flag it as a typo.
The valid warning token is still unknown to Eclipse 2023-12. I think the previously suggested fix is still acceptable, which was to simply recognize the token and raise a "cannot analyze" info.
