javac understands for --source both "1.5" and "5" and also "1.9" and
"1.10". Tested with openjdk13.
javac understands for --release "7" and higher. javac 10 had
support for "6".
This means, not all variants work in all constellations, but PMD
should understand now the correct version regardless how it is
specified.
Newer java compiler (java 9+) support the `--release` option to choose
for which version of the JRE to compile. This parameter only takes
simple values as documented by `javac --help`:
```
--release <release>
Compile for a specific VM version. Supported targets: 6, 7, 8, 9, 10, 11
```
adding these versions to pmd allows the use of the same versions (6, 7
and 8) with PMD as with the compiler, thus removing the need to juggle
between single digit versions for the compiler and 1.<x> for PMD.
Fixes#1531
In case we determined, that the method argument is a method call,
then we skip now completly trying to determine the correct argument
type. It was half-way fixed before for the first if condition, but
we still evaluated e.g. the allocation expression in
print(new Integer(1).toString());
and wrongly assumed, the argument type would be an integer,
without taking into account the `toString()` method call.
The same happened with
privateBooleanMethod(s, "true".equals(s));
where we took the 2nd argument as a literal and assumed
it is a "String", while the method call result actually
is a boolean.
With this change now, the false positive is fixed.
However, since we don't determine the argument type at all, the
method is matched solely on argument count. This will obviously
lead to wrong matches if method overloading is used.
This commit stops checking for UR anomalies in the
DataflowAnomalyAnalysis rule in Java. Note, I retained the UR anomaly
test, but changed the expected number of errors to zero.
Addresses: #1636
Retrieving the enclosing class might result in a LinkageError or
ClassFormatError.
For now this error is just logged as a warning and ignored.
fixes#2042
Comparison was failing because the test file was checked
out with CRLF and the expected result is written with LF.
Maybe we should normalise consistently across tests. Using
PMD.EOL in tests is just code obfuscation.
java12 preview and java13 preview is now not possible anymore
see
src/test/resources/net/sourceforge/pmd/lang/java/ast/jdkversiontests/java12
src/test/resources/net/sourceforge/pmd/lang/java/ast/jdkversiontests/java13