JEP 286: Local-Variable Type Inference

#1

Post by azth » Thu, Mar 10, 2016, 6:50 PM UTC

JEP 286: Local-Variable Type Inference
openjdk.java.net

Re: JEP 286: Local-Variable Type Inference

#2

Post by talideon » Thu, Mar 10, 2016, 6:59 PM UTC

About time, given how long C# has had local type inference.

Re: JEP 286: Local-Variable Type Inference

#3

Post by scalesolved » Thu, Mar 10, 2016, 7:02 PM UTC

I hope this gets added to the language, we use Lombok heavily where I work and find it pretty great with it's val class that allows type inference, although it requires an explicit import and can't be used within Lambdas.

The website isn't the prettiest but Lombok is a fantastic addition to a Java codebase and massively reduces the amount of boiler plate often associated with Java. A list of Lombok features https://projectlombok.org/features/index.html

Java 8 + Lombok + Guava == happy developers (well at least in my case :) ).

Re: JEP 286: Local-Variable Type Inference

#4

Post by andyfleming » Thu, Mar 10, 2016, 7:03 PM UTC

This would definitely be a nice language feature to see in Java. It's one (of many) of the reasons I'm attracted to Kotlin (https://kotlinlang.org/).

Re: JEP 286: Local-Variable Type Inference

#5

Post by paramk » Thu, Mar 10, 2016, 7:16 PM UTC

Scala ?

Re: JEP 286: Local-Variable Type Inference

#6

Post by vivin » Thu, Mar 10, 2016, 7:16 PM UTC

This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way:

  var list = new ArrayList();

There is no way to infer the type of the generic parameter. So we will go back to doing:

  var list = new ArrayList();

Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond. You also end up using fewer characters in general with var even without being able to use the diamond.

Regarding val vs let, I prefer let simply because it's harder to accidentally type let vs typing var instead of val (or vice versa).

Re: JEP 286: Local-Variable Type Inference

#7

Post by emmanueloga_ » Thu, Mar 10, 2016, 7:23 PM UTC

I wonder if this JEP draw any inspiration of http://www.eclipse.org/xtend/. For those new to xtend, think of it as xtend is to java like coffeescript is to javascript.

I wish most of the xtend enhancements were integrated to java asap!

Re: JEP 286: Local-Variable Type Inference

#8

Post by merb » Thu, Mar 10, 2016, 7:33 PM UTC

var + val would be great.

Re: JEP 286: Local-Variable Type Inference

#9

Post by namelezz » Thu, Mar 10, 2016, 7:35 PM UTC

vivin wrote: post #6

This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way: var list = new ArrayList (); There is no way to infer the type of the generic parameter. So we will go back to doing: var list = new ArrayList (); Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond…

I hope this gets rejected. The given examples are too ideal as they are all using familiar Java standard APIs. I doubt if it's a good idea in practice since you can end up with unreadable code when integrating with third party APIs.

Re: JEP 286: Local-Variable Type Inference

#10

Post by kodablah » Thu, Mar 10, 2016, 7:35 PM UTC

vivin wrote: post #6

This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way: var list = new ArrayList (); There is no way to infer the type of the generic parameter. So we will go back to doing: var list = new ArrayList (); Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond…

> Regarding val vs let

I like the approach mentioned of just reusing final for immutability.