Live data from Hacker News

JEP 286: Local-Variable Type Inference

openjdk.java.net

21–30 of 132 posts

Re: JEP 286: Local-Variable Type Inference

#21

I for one actually prefer to put a different type on the variable than the implementation. I.e. in the given case, I would actually use: `List a = new ArrayList ();` I know that for some things it is convenient, but I appreciate the reminder to treat interface and implementation as distinct concepts.

For local variables within the body of a method it doesn't really matter. As long as the method signature is expressed in interfaces, you should be able to use whatever implementations you want within the method body.

Re: JEP 286: Local-Variable Type Inference

#23
In their list of risks there's one missing: it makes changing the return type of a method to a subclass a subtly breaking change. Say some api defines a method,

Collection getNames() { ... }

and in your code you do

var names = getNames(); if (...) names = Collections.emptySet();

Now, if the api later changes getNames() to be

List getNames() { ... }

your code breaks. That's one of the advantages of only allowing this on final variables (besides reusing an existing keyword): it means this can't happen. Of course you already have a problem if the class has subclasses but I would argue that this is more subtle and problematic.

Re: JEP 286: Local-Variable Type Inference

#24
I hope this goes through!

A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard.

The reason was this: quite often type signatures correctly modelling a domain ends up being pretty hard to read. In a good and proper API, this happens in particular whenever something is composable and is, in fact, composed (if one can say that). I suppose one can say that, for Scala, it took a bit of time before people figured out how to do this properly, rather than just hacking the type system, but I feel that the ecosystem is more or less there now... YMMV though...

As an example: in something like Slick (a functional-relational mapper) in Scala you end up with monads to model your SQL query. One advantage this has is compile errors whenever you're doing something wrong (i.e. more typesafe), but the types that a SQL query representation ends up with will necessarily be pretty hard to read and practically impossible to write (you could have a Query of a long chain of other types for example if you're querying multiple columns). In this example, somebody writing the query might not care about the type of the query. They will care about what the query will end up returning when executed though. I suppose it will lead to trouble when you can't read the type signatures well enough and try to figure out the compiler error, but I reckon it's better to have an error, than to see it fail runtime (at least in my world :). It's easier and safer to do maintenance too, since the compiler and IDEs can know how things should work.

In any case, you could conclude that, in a statically compiled language where you do not have type inference, you'll end up trading in preciseness in the model of the domain, in order to have readable code from the callsite. In turn, this leads to less typesafe code.

One challenge that Java will have even when implementing this though, is how to move the entire ecosystem to something that is indeed more typesafe. This only works if the APIs are doing this right.

EDIT: typos, language and less parens

Re: JEP 286: Local-Variable Type Inference

#25

Hey look, it's something else that's been implemented in almost every other JVM language that hasn't made it into Java yet.

Being conservative about what you add to the language is a feature, not a bug. Not all languages need to be on the cutting edge (even if I personally prefer the languages that are)

Re: JEP 286: Local-Variable Type Inference

#26
post #11
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've been doing List list = new ArrayList (); Isn't that good enough?

No.

The List is almost as redundant as the RHS was.

Re: JEP 286: Local-Variable Type Inference

#27
post #22

Cool, this will help Java from looking so bad: https://gist.github.com/mythz/7e263820332a0fcea766 From Java LINQ Examples: https://github.com/mythz/java-linq-examples

That code is a wrong equivalence — Java's lambdas make that code already a lot more readable, but somehow weren't used in that example.

Re: JEP 286: Local-Variable Type Inference

#28
post #11
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've been doing List list = new ArrayList (); Isn't that good enough?

For your example, it makes no difference. However, take a look at the other example mentioned at the beginning:

    var stream = list.stream();   // infers Stream
How would you write it in order to take advantage of type inference?

Re: JEP 286: Local-Variable Type Inference

#30
post #25

Hey look, it's something else that's been implemented in almost every other JVM language that hasn't made it into Java yet.

Being conservative about what you add to the language is a feature, not a bug. Not all languages need to be on the cutting edge (even if I personally prefer the languages that are)

See Brian Goetz's talk on language stewardship (https://www.youtube.com/watch?v=2y5Pv4yN0b0). I'm sure nobody wants to add new and interesting features to Java more than the people who work on the language every damn day, but they've made a strong commitment to the community to not break existing code.
Post reply on HN