I encountered some error messages on my code that can be correctly compiled and run, meaning that these errors could be false positives. After simplifying the code, I found that these false positives could be caused by incorrect name shadowing for type parameters.
Environment
Operating System: Linux
JDK version: 21
Visual Studio Code version: 1.94.2
Java extension version: 1.35.1
Steps To Reproduce
Create an empty java project and open it with vscode.
Create a package demo and a App.java file in this package.
Paste the code below into App.java:
package demo;
interface BinaryExpr {
interface Op { }
Op getOperator();
}
abstract class AbstractBinaryExpr implements BinaryExpr {
private final Op op;
public AbstractBinaryExpr(Op op) { this.op = op; }
@Override
public Op getOperator() {
return op;
}
}
final class ArithExpr extends AbstractBinaryExpr {
enum Op implements BinaryExpr.Op {
ADD, SUB
}
public ArithExpr(Op op) { super(op); }
}
public class App {
public static void main(String[] args) {
var e = new ArithExpr(ArithExpr.Op.ADD);
System.out.println(toStr(e));
}
public static String toStr(ArithExpr e) {
return switch(e.getOperator()) {
case ADD -> "+";
case SUB -> "-";
};
}
}
##### Current Result
You will see the following three error messages:
```java
// ...
public static String toStr(ArithExpr e) {
return switch(e.getOperator()) { // Error 1: A switch expression should have a default case
case ADD -> "+"; // Error 2: ADD cannot be resolved to a variable
case SUB -> "-"; // Error 3: SUB cannot be resolved to a variable
};
}
Expected Result
No error messages are expected because java compiler can handle it correctly.
Additional Informations
If you rename the type parameter Op and its following occurrances in class AbstractBinaryExpr into O, the error messages will disappear. This hints that the return type Op of AbstractBinaryExpr.getOperator() may be resolved to the Op in the superclass BinaryExpr rather than the type parameter.
I encountered some error messages on my code that can be correctly compiled and run, meaning that these errors could be false positives. After simplifying the code, I found that these false positives could be caused by incorrect name shadowing for type parameters.
Environment
Steps To Reproduce
demo
and aApp.java
file in this package.App.java
:interface BinaryExpr { interface Op { }
}
abstract class AbstractBinaryExpr implements BinaryExpr {
private final Op op;
}
final class ArithExpr extends AbstractBinaryExpr {
enum Op implements BinaryExpr.Op {
ADD, SUB
}
}
public class App {
}
Expected Result
No error messages are expected because java compiler can handle it correctly.
Additional Informations
If you rename the type parameter
Op
and its following occurrances in classAbstractBinaryExpr
intoO
, the error messages will disappear. This hints that the return typeOp
ofAbstractBinaryExpr.getOperator()
may be resolved to theOp
in the superclassBinaryExpr
rather than the type parameter.