[Java][False positive?] Generic wildcard types should not be used in return parameters (squid:S1452)

1,539 views
Skip to first unread message

apu...@redhat.com

unread,
Jun 4, 2018, 9:06:05 AM6/4/18
to SonarQube
Hello,

I have a reported issue by Sonar "Generic wildcard types should not be used in return parameters (squid:S1452)"

The thing is that the method is called in another place where the expected return type of an implemented method of an interface which is part of a dependency is using the wildcard types.
It seems to me that I can't get rid of it.

If I modify the method reported by Sonar, the "implemented" other method is complaining.
from "public CompletableFuture<List<? extends SymbolInformation>> getDocumentSymbols()" to "public CompletableFuture<List<SymbolInformation>> getDocumentSymbols()"

The error is "Type mismatch: cannot convert from CompletableFuture<List<SymbolInformation>> to CompletableFuture<List<? extends SymbolInformation>>"

and I can't modify the documentSymbol method as it is part of a dependency.

Is it a false-positive or I misunderstood something?

regards,


Andrei Epure

unread,
Jun 7, 2018, 11:45:02 AM6/7/18
to SonarQube
Hi Aurélien,

From a github search, I see that DocumentSymbolProcessor.getDocumentSymbols() only gets called inside CamelTextDocumentService.documentSymbol().

So the easiest thing is to make the getDocumentSymbols() method return List<SymbolInformation> and make the async call inside CamelTextDocumentService.documentSymbol()

  return CompletableFuture.supplyAsync(() -> {
    return new DocumentSymbolProcessor(openedDocuments.get(params.getTextDocument().getUri())).getDocumentSymbols();
  });

What do you say?

Regards,
Andrei

P.S.: Starting June 11th we'll have a new awesome forum. Details here

Andrei Epure | SonarSource

Software Developer

https://sonarsource.com


Are you using SonarLint in your IDE?


Aurélien Pupier

unread,
Jun 8, 2018, 4:31:32 AM6/8/18
to Andrei Epure, SonarQube
Hello Andrei,

effectively, it avoids the warning in Sonar.
It sounds to me more like a hack than a real better practice.
I would prefer to keep the async call in the  DocumentSymbolProcessor to stay consistent with my other classes and also try to keep as simple as possible the CamelTextDocumentService.

thanks for the hint
I will think a bit more about it in coming days on the action I will take (mark as false-positive or follow your advice or maybe be able to ask changing the API on upstream project)

regards,

--
Important: this SonarQube Google Group will close on June 11th, 2018, in order to move to a new forum to power even more community discussions. See details in this post: https://groups.google.com/d/msg/sonarqube/BbSZz-JnhVM/DavhMueEAAAJ
---
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/BLXAdLEL9QE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/2aaccfd5-1cd0-402b-9045-78c0eab1d5b0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

AURÉLIEN PUPIER

SENIOR SOFTWARE ENGINEER, FUSE TOOLING

Red Hat France

apu...@redhat.com    IM: apupier

Andrei Epure

unread,
Jun 8, 2018, 4:49:00 AM6/8/18
to Aurélien Pupier, SonarQube
Hi Aurélien,

I see what you mean. In this case, you should suppress the warning on your method. You can find docs here on how to use @SuppressWarnings to supress a rule.

The rule doesn't raise the warning in the class that implements the external interface because of the @Override annotation. But on the other class, you define your own contract, so the rule raises the issue. It's a false positive only in the context of your application.

Regards,
Andrei

P.S.: Starting June 11th we'll have a new awesome forum. Details here

To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
--

AURÉLIEN PUPIER

SENIOR SOFTWARE ENGINEER, FUSE TOOLING

Red Hat France

apu...@redhat.com    IM: apupier

--
Reply all
Reply to author
Forward
0 new messages