type inference - Does Java 10 provide a val keyword? If not, why not?

Question

Java 10 brings a C#-like var keyword for local type-inference.

But does Java 10 also provide a val keyword, as is found in Scala?

val would work like var but the binding would be final.

var x = "Hello, world. ";
x = "abc"; // allowed

val y = "Hello, world. ";
y = "abc"; // forbidden

If it does not, is there a reason that this is the case?

question from:https://stackoverflow.com/questions/49426958/does-java-10-provide-a-val-keyword-if-not-why-not

Answer 1

There is no val in Java 10, as stated in JEP 286: Local-Variable Type Inference:

Syntax Choices

There was a diversity of opinions on syntax. The two main degrees of freedom here are what keywords to use (var, auto, etc), and whether to have a separate new form for immutable locals (val, let). We considered the following syntactic options:

• var x = expr only (like C#)
• var, plus val for immutable locals (like Scala, Kotlin)
• var, plus let for immutable locals (like Swift)
• auto x = expr (like C++)
• const x = expr (already a reserved word)
• final x = expr (already a reserved word)
• let x = expr
• def x = expr (like Groovy)
• x := expr (like Go)

After gathering substantial input, var was clearly preferred over the Groovy, C++, or Go approaches. There was a substantial diversity of opinion over a second syntactic form for immutable locals (val, let); this would be a tradeoff of additional ceremony for additional capture of design intent. In the end, we chose to support only var. Some details on the rationale can be found here.

And here's the main reasoning:

I know this is the part people really care about :) After considering the pros and cons at length, there appears to be an obvious winner -- var-only. Reasons for this include:

• While it was not the most popular choice in the survey, it was clearly the choice that the most people were OK with. Many hated var/val; others hated var/let. Almost no one hated var-only.

• Experience with C# -- which has var only -- has shown that this is a reasonable solution in Java-like languages. There is no groundswell of demand for "val" in C#.

• The desire to reduce the ceremony of immutability is certainly well-taken, but in this case is pushing on the wrong end of the lever. Where we need help for immutability is with fields, not with locals. But var/val doesn't apply to fields, and it almost certainly never will.

• If the incremental overhead of getting mutability control over that of type inference were zero, there might be a stronger case, but it was clear that many people found two different leading keywords to be a distraction that kept their eyes from quickly settling on the important stuff. If variable names are more important than types, they're more important than mutability modifiers too.

(Source)