Var keyword in Java

With Java 10 or +, we can use var keyword for declaration. At initialization, a type is going to be inferred by the compiler.

What happens when the class I instantiate and assign to the variable declared with var, is the implementation of the interface? which type is it going to be inferred, Interface or the implementation?

My 2 cents to correct the question and answers:

1. The var is NOT a Java keyword. It's a reserved type name. It seems not a big difference but in fact, it IS:

var var = 0;

Here var is a variable name too, so the var can be used as a type name, but there is no restriction like for regular keyword (i.e. we can have a variable named var too).

2. The actual type of the variable IS decided by the Java compiler on the line where the variable declared, at compile-time, but the type is NOT actually the exact implementation you use on the right side of the expression. See this code:

var i = true ? Integer.valueOf(1) : "ABC";

The Java compiler needs to pick a type for variable i which will satisfy both branches. It could be a) Object, b) Serializable, c) Comparable, or combination, or all three. We don't care and don't know.

Answer to your question:

>What happens when the class I instantiate and assign to the variable declared with var, is the implementation of the interface? which type is it going to be inferred, Interface or the implementation?

Inferred type of the variable will be exactly the class, reference to the instance of which you're assigning to the variable declared with var.

Regarding "interface" point: if it (class of the object, reference to which you assign to variable declared with "var") is an implementation of some interface, what do you think will happen if that class implements two or more interfaces? how, do you think, Java should decide on which super-type (i.e. interface) to infer for the variable? this is impossible even by basing our judgement purely on a logic (without any relation to Java) - there will be no "source of truth", by which, Java would be able to decide on this.

Motivation for var keyword:

Remember, that the only stated purpose of using var, according to the language designers (since JDK 10+), has been the point to beautify the code and make it more readable (which, I personally think, is a non-sense as having "var" in Java, is worse than having explicit types, and in many ways so).

For example, this code:

URL url = new URL("http://www.oracle.com/"); 
URLConnection conn = url.openConnection(); 
Reader reader = new BufferedReader(
new InputStreamReader(conn.getInputStream()));

is (according to official JEP document) less clear to read than:

var url = new URL("http://www.oracle.com/"); 
var conn = url.openConnection(); 
var reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));

Implementation details:

var was introduced with the purpose of serve the cleaner/better readability and NOT to amend the Type System of the Java language. That's why, you can't use it in the class level (for static or instance) fields, because fields might be used with polymorphism (might receive different implementation types, might be injected by IoC, or etc.) and at the bytecode, it's not possible to dynamically change the field type for each different case.

Update:

Why I think "var" is bad and why I try to avoid it?

Well, for several reasons:

1. code gets actually harder to read, and not only in a sense of merely reading it, but also in a sense, that you may have hard times when trying to understand what is the actual type you are getting the reference to. Imagine if the actual object creation expression is some long builder pattern code.. or factory pattern call.. or etc. you basically have to go and open/decompile the source and see what you get. So, it's harder to read and harder to understand;
2. this will often lead (especially a bit less experienced in Java) engineers to confusion whether typing becomes dynamic or keeps static;
3. polymorphic calls are not supported and polymorphism, in general, is not possible, because compiler cannot infer different types with the same code;
4. code actually gets inconsistent, as you'll be having explicit types for fields and "var"s for local variables. This will also (but not only) confuse newcomers to Java;
5. maybe not that important.. but this can be important as well: "var" will also break backwards compatibility, as you won't be able to downgrade to the Java version below 10.

The other answers so far don't stress one important point, the distinction between compile-time deducible type and run-time instance class.

Suppose we have

var data = Collections.singleton("test");

Then, the compiler can see that Collections.singleton("test") is declared to return Set<String>. So data effectively gets declared as Set<String> (not e.g. Collection<String> nor Object nor Collections.SingletonSet). Set<String> is the most specific info the compiler can find out.

When running, the instance referenced in data will be of some implementation class (e.g. Collections.SingletonSet), decided upon by the Collections.singleton() method, meaning that data.getClass() will not return the Set class, but something different that implements the Set interface, i.e. Collections.SingletonSet.

So we have to consider three types:

1. The run-time class of the instance that gets assigned to the variable (e.g. a Collections.SingletonSet). This will of course always be compatible with (2) and (3), and cannot be known at compile-time.
2. The compile-time type of the expression that you assign to the variable (e.g. Set<String>).
3. The declared type of the variable. Classically, you'd find that explicitly left of the variable name, and when using the var keyword, the compiler treats it as if declared with the type from (2) (i.e. Set<String>).

The 'official' Local Variable Type Inference style guide (https://openjdk.java.net/projects/amber/LVTIstyle.html) raises this concern, but says:

> "It must be reiterated here that var can only be used for local
> variables. It cannot be used to infer field types, method parameter
> types, and method return types. The principle of "programming to the
> interface" is still as important as ever in those contexts."

and

> "If, as recommended in guideline G2, the scope of the local variable
> is small, the risks from "leakage" of the concrete implementation that
> can impact the subsequent code are limited."

The type will be exactly the same of the value the variable gets assigned to.

In case you are more concerned with interface over implementation idea: you can create function which returns interface type but creates a specific implementation instance inside.