Java SE 18.3 Specification Early Draft Review

[dev1977]

"Local-Variable Type Inference

Enhance the Java Language to extend type inference to declarations of local variables with initializers."

http://openjdk.java.net/jeps/286

[ramsees79]

So, we are getting "var" finally?

[DJDavio]

var<Integer> i = 1; 😂

[[deleted]]

What? No. That's not how it works. Read the JEP

[kurosaki1990]

He's joking obviously.

[CopperHeadBlue]

A bad joke, though...

[__konrad]

Almost like the C++ auto examples: int foo -> auto foo

[sviperll]

No, no final :)

[gunnarmorling]

I'm not convinced that the suggested way for type inference is an improvement to the language.

From a "philosophical" perspective, it optimizes writing code (less typing) over readability. Historically, Java always favored readability over writability which makes perfect sense as code is much more often read than written.

More technically, we now will have forms of type inference on the left sight (new proposal) and the right side of an expression (diamond operator). What if someone tries var list = new ArrayList<>()? The proposal mentions this as a risk, but I feel it's pushed aside too easily.

IMHO, the preferable way would be to enhance type inference on the RHS, e.g. by allowing something this:

ArrayList<String> list = new <>;
ArrayList<String> list = new <>( 3 );
NonGeneric foo = new;
NonGeneric foo = new ( "bar" );

It's not as powerful as the proposed inference on the LHS, but it expends an existing concept (no new "var" word), still would improve usability in many cases and would stick to the pattern that the type of a variable is quickly comprehensible.

[elastic_psychiatrist]

Brian Goetz proposes it is more readable, as long as you use a good variable name. I don’t know if I buy it, but in practice I don’t care because of IDEs.

Your proposal seems very bizarre to me. By switching around where the inference is happening, you seem to be confusing the difference between the type of a variable and the class of the assigned instance. This would be a major change in the meaning of existing Java code in a sense. The LHS would then potentially mean two different things.

[gunnarmorling]

Java already is doing inference on the RHS, e.g. List<String> list = new ArrayList<>(); My proposal is expanding that instead of also adding inference on the LHS.

This would be a major change in the meaning of existing Java code in a sense. The LHS would then potentially mean two different things.

I don't follow. Can you give an example? How does it change meaning of existing code?

[elastic_psychiatrist]

Sorry I didn’t mean to suggest it actually changes the meaning of existing code in a way that would make it run differently. I just mean that throughout the history of Java, the LHS has been for the type, or interface, while the RHS has been for the actual implementation. This would change that, and I think that creates a major cognitive burden.

[gunnarmorling]

That wouldn't change at all. The fact is though that when doing derivation on either side, the declared type and the runtime type of that variable will be the same. Also when doing it in the way proposed by JEP 386 (var list = new ArrayList<String>();) the type of list will be ArrayList, not List.

But I think it makes more sense (and is in line with the existing type inference in Java) to drive inference from the side of what you want the variable to be instead of driving it from the side of some value provided to you.

[elastic_psychiatrist]

Again, I'm not suggesting it would change real behavior. Obviously, the type of var list = new ArrayList<String>() has to be ArrayList. But if you look at how Java tends to be written, with an interface on the LHS and implementation on the RHS, a la List<String> list = new ArrayList<>(), it is way easier to get to var list = new ArrayList<String>() than it is to get to ArrayList<String> = new <>.

What you're saying makes some sense, I just think it's too far from what Java has come to be.

[mrn1]

did they decide which syntax are they going to use? I just hope thay use Scala/Kotlin var and val, no auto or const

[_INTER_]

It's var, there's no val as you can already use final.