DiamondOperatorForVariableDefinitionCheck: fixing violation leads to a compilation error in Java 7

[rdiachenko]

Check generates violation in the 5th line:

1. import java.util.ArrayList;
2. public class A {
3.  public void m() {
4.      List<Bar> fst = new ArrayList<>();
5.      List<Foo> snd = new ArrayList<Foo>(fst); // violation!!
6.  }
7.  private class Foo {}
8.  private class Bar extends Foo {}
9. }

We can fix this violation as follows:

1. import java.util.ArrayList;
2. public class A {
3.  public void m() {
4.      List<Bar> fst = new ArrayList<>();
5.      List<Foo> snd = new ArrayList<>(fst);
6.  }
7.  private class Foo {}
8.  private class Bar extends Foo {}
9. }

But the fixed version of code stops compiling on Java 7 with such an error:

Type mismatch: cannot convert from ArrayList<A.Bar> to List<A.Foo>

I found this JEP-101 which was released within Java 8. Probably that is why everything is ok under Java 8.

[AustinShalit]

Does checkstyle support java 7 anymore? If not, then we should close this issue.

[rnveach]

We support all versions of Java up to 8.

@romani Is this issue valid?
We can't know if the constructor is typed or not. We could assume it is, and must check if fst declares the same parameter type as snd (Bar versus Foo).

[romani]

we support all that is compilable by javac, smth that checkstyle demand and cause non-compilable sources is a problem of Check.
we work ONLY on compilable sources, so we presume that all is correct.

We do not know version of java user is working on, all Checks suppose to work on all versions.
Issue is valid, we just need to have an option to skip validations of such cases if new options is activated to let user to work on java7.

[rnveach]

According to first post, user got an exception on code change using Java 7.
However, the same code compiles fine without problem in Java 8.

It seems there were changes to make type parameters work in more cases.
See the following references:
https://stackoverflow.com/questions/25818287/why-does-the-diamond-operator-not-work-for-java-util-collections-methods-in-java
https://stackoverflow.com/questions/27134626/when-does-diamond-syntax-not-work-in-java-8

I agree with @romani 's statement now that we must find a way to skip these cases.
We will need a new property for the check like skipJava7Limitations or strictJava8 or some such.

I think the only way we can identify these cases is if we know that the variable being sent to the constructor is a different type than the new variable being assigned.
In short, it should be skipped because <Foo> on line 5 doesn't equal <Bar> on line 4.

@romani You agree?

[romani]

yes, but slight change for name is required to my mind ....

JEP-101 looks like not about c-tors only, looks like all c-tor/methods with parameters are affected. As Checkstyle is not type-aware tool , we need to skip all methods/c-tor with arguments. So it might be better to name property as is skipMethodsCtorsWithParameters default is FALSE (one day jdk7 will stop exists). In documentation we should reference JEP and explain reason of property and how to use it.

@rnveach , are you ok with this ?

[rnveach]

yes, that is fine. I was aiming to atleast still cover some cases, but we can skip all for now.

@AustinShalit you can start this issue if you still want to.

[AustinShalit]

Sounds good 👍