Having this:
public <T extends DataAgent> DataProcessor<? extends DataAgent> resolveProcessor(
final String response, T dAgent) throws Exception {
if (dAgent.getType() == RESULT_TYPE.INLINE) {
return InlineParser.parse(response, (InlineDataAgent) dAgent);
}
return DefaultParser.parse(response, (DefaultDataAgent) dAgent);
}
The code work as it should but i struggle with a warning that says ‘Generic wildcards should not be used in return types’.
Both Agent classes extending from DataAgent but they are specialized with specialized fields. Therefore i need the cast to work with the specialized subclass.
The DataProcessor is also a interface and the implementations are bounded to either DefaultDataAgent or InlineDataAgent.
How can i solve the wildcard problem?
0
Your question is about a linter rule. Linters are written by opinionated humans, and they aren’t generally peer reviewed. In contrast to a language spec which is written, reviewed, revised, agonized about, and effectively ‘forced onto the entire community’.
In other words, often ‘this linter tool tells me X is wrong’ is best answered by: “Well, then ditch the dumb tool, nobody is forcing you to use it!”.
Thus, one easy solution, if you’re convinced you’ve done it right, is just that. Stop using it / disable that rule.
What is the nature of wildcards in generics?
You have a DataProcessor<? extends DataAgent> as return type which the linter is complaining about.
To explain the intent behind that warning, let’s use a type everybody understands, and where all variances are much easier to explain: List.
Let’s say I have a list that can contain any number.
You might think that would be a List<? extends Number>. But that is incorrect. Question mark is best read as just that: Say “I do not know” as you read it out. a List<? extends Number> is pronounced as: “A list containing I-do-not-know… but I do know that whatever it is, it is a Number or a subtype of Number”.
In other words, it might be a List<Double>. It might be a List<Integer>. You don’t know. And because you don’t know, anybody that calls this method cannot add anything to this list. Not because it is immutable – but because there is no expression in java that is both a Double and an Integer at the same time, and yet, that’s the only thing you can safely add here as it might be either one. In fact, I lied – there is an expression that is both Double and Integer at the same time: the null literal. Indeed, list.add(null); works on a List<? extends Whatever>… and nothing else will when invoking add on such a list.
How useless.
In contrast, a List<Number> means, specifically, a ‘a list containing all sorts of numbers’. You can add doubles to this list, you can add integers to this list.
Here, your method should know what it is returning.
If your method is returning a ‘split’ type (where it returns either a List<Integer> or a List<Double> depending on the phase of the moon for example), your method just sucks. We don’t write methods that return 2 wildly different concepts – instead we write 2 methods then. I think we all agree this is a really bad method:
public Object returnUserNameOrId() {
if (systemIsIdBased()) return 5;
else return "username";
}
Returning either an Integer or a String is just not ‘java-like’. Java is not designed for this, the core libs don’t have an Either<Left, Right>, no core library function does this.
That’s what the linter tool is complaining about. Opinion: The linter rule is pretty good. You should indeed rewrite this method.
So, if in the PECS getup (Producer Extends, Consumer Super), if ‘producing’ is not a relevant aspect of it, just write DataProcessor<DataAgent>. If it is relevant, write 2 methods, or make a type var that the caller can somehow influence and return <A extends DataAgent> DataProcessor<A> instead.