Maven Compilation Error: (Use -Source 7 or Higher to Enable Diamond Operator)

Compilation error with generics and ternary operator in JDK 7

The JLS SE 8 says at (§15.2):

When some expressions appear in certain contexts, they are considered poly expressions. The following forms of expressions may be poly expressions:

  • Parenthesized expressions (§15.8.5)

  • Class instance creation expressions (§15.9)

  • Method invocation expressions (§15.12)

  • Method reference expressions (§15.13)

  • Conditional expressions (§15.25)

  • Lambda expressions (§15.27)

So from this part of the spec is clear that conditional expressions, the ternary operator, can be considered poly expressions. But not all conditional expressions can be considered poly expressions, only reference conditional expressions according to (§15.25). The conditions under which a reference conditional expression can be considered a poly expression are clarified at (§15.25.3):

A reference conditional expression is a poly expression if it appears in an assignment context or an invocation context (§5.2. §5.3). Otherwise, it is a standalone expression.

Where a poly reference conditional expression appears in a context of a particular kind with target type T, its second and third operand expressions similarly appear in a context of the same kind with target type T.

The type of a poly reference conditional expression is the same as its target type.

Check that in your example the conditional expression appears in an assignment context because according to (§14.17):

When a return statement with an Expression appears in a method declaration, the Expression must be assignable (§5.2) to the declared return type of the method, or a compile-time error occurs.

So at the end of the day, what all this means? This implied that when conditional expressions are poly expressions, the target type is "pushed down" to each operand. This way the compiler can attribute each part of the condition, against the target. In your case the target is List<String>. If we check the definition of the emptyList() method we have:

@SuppressWarnings("unchecked")
public static final <T> List<T> emptyList() {
return (List<T>) EMPTY_LIST;
}

So with the target List<String>, the compiler can infer that T == String and the code is accepted.

eclipse not inserting diamond operator in a java 8 project

I had this issue just a few minutes ago and solved it half way through typing out an SO question.

Eclipse's auto-complete apparently prioritized the old-style generic syntax after I had fiddled with the advanced content assist settings a while ago. Try resetting Java > Editor > Content Assist > Advanced to defaults; this was what fixed it for me and returned auto-complete to inserting the diamond syntax by default.

Why can't Java 7 diamond operator be used with anonymous classes?

This was discussed on the "Project Coin" mailing list. In substance (emphasis mine):

Internally, a Java compiler operates over a richer set of types than
those that can be written down explicitly in a Java program. The
compiler-internal types which cannot be written in a Java program are
called non-denotable types. Non-denotable types can occur as the result
of the inference used by diamond. Therefore, using diamond with
anonymous inner classes is not supported since doing so in general would
require extensions to the class file signature attribute to represent
non-denotable types, a de facto JVM change
. It is feasible that future
platform versions could allow use of diamond when creating an anonymous
inner class as long as the inferred type was denotable.

Note that it is not supported in Java 8 either but will be included as a new feature in Java 9 (Item 3 of "Milling Project Coin").

Maven points to incorrect java folder when I upgrade solr 4.4 in pom.xml

I solved this issue. In my machine java was pointing to some other JRE. I uninstalled that JRE. now it is working fine.

maven-exec-plugin throws exception for no apparent reason

So... revisiting this... if you use Windows PowerShell, you will get the exception I originally reported. If, however, you use cmd.exe, then you should be able to run the class with the command as I posted (with or without wrapping double-quotes).

spring boot with gradle 3 and java 7 fails at server startup

With Spring Boot 1.4, the default Jetty version is 9.3, which requires JDK8.

If you want to stick to JDK7, you can use Jetty 9.2 as explained in the reference documentation.



Related Topics



Leave a reply



Submit