Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP 286: Local-Variable Type Inference

openjdk.java.net

Post reply on HN
Print view View original

31–40 of 132 posts

Re: JEP 286: Local-Variable Type Inference

#31

Post by the_af »

linuxhansl wrote: post #12

Hmm... I agree it looks nicer. Who's typing Java code all by hand these days, though? There various IDEs that save me all the typing. It's also nice to be able to go the declaration of a variable to see exactly what type it is - that's mostly for code not written by myself, or old code that I do not remember. For local variable that's fine (I hope we won't infer types this way for method parameters), so I guess I lik…

> Who's typing Java code all by hand these days, though? There various IDEs that save me all the typing.

Reducing boilerplate mostly helps with reading code, not with writing it.

Re: JEP 286: Local-Variable Type Inference

#32

Post by wvenable »

plesner wrote: post #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…

I think in practice this would be pretty rare. At least coming from a C# background it doesn't seem to be an issue I've ever encountered.

Re: JEP 286: Local-Variable Type Inference

#33

Post by namelezz »

msbarnett wrote: post #13
namelezz wrote: post #9

Earlier quoted context omitted.

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.

> I doubt if it's a good idea in practice since you can end up with unreadable code when integrating with third party APIs. This works perfectly fine in practice as can be seen using comparable constructs in C#, C++, and many other mainstream languages. If anything it's more readable, since your code isn't littered with redundant type info.

> If anything it's more readable, since your code isn't littered with redundant type info.

I fail to see the redundant type info.

Example 1:

int maxWeight = blocks.stream() .filter(b -> b.getColor() == BLUE) .mapToInt(Block::getWeight) .max();

"int" is not redundant type info here.

Example 2:

List list = new ArrayList(); // (1)

var list = new ArrayList(); // (2)

Many would say List in (1) is redundant but I would argue otherwise. The intention of List in (1) is to reference to the underline ArrayList through List interface. (1) is trying to encourage programming to an interface while (2) just completely destroys the practice by inferring the type for list variable to be ArrayList. That means subsequent method invocations after (2) can be methods from ArrayList not List.

Re: JEP 286: Local-Variable Type Inference

#34

Post by seanjensengrey »

scalesolved wrote: post #3

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://p…

If you have an opinionated style guide, I would love to read it. Something like this [0] but for Java.

[0] https://gist.github.com/seanjensengrey/a08910b0d204b037c2ba

Re: JEP 286: Local-Variable Type Inference

#35

Post by javaq »

scalesolved wrote: post #3

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://p…

Are there any repos you can point to that make idiomatic use of J8 + Lombok + Guava as an example for people interested?

Re: JEP 286: Local-Variable Type Inference

#36

Post by biehl »

scalesolved wrote: post #3

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://p…

My experience is similar, however more like: Groovy === happy developers

Re: JEP 286: Local-Variable Type Inference

#37

Post by usrusr »

linuxhansl wrote: post #12

Hmm... I agree it looks nicer. Who's typing Java code all by hand these days, though? There various IDEs that save me all the typing. It's also nice to be able to go the declaration of a variable to see exactly what type it is - that's mostly for code not written by myself, or old code that I do not remember. For local variable that's fine (I hope we won't infer types this way for method parameters), so I guess I lik…

> Who's typing Java code all by hand these days, though? > There various IDEs that save me all the typing.

Some truth in that, it should be safe enough to assume that the lightweight editor crowd has long self-selected out of java. I often do write-time type inference by declaring anything as an int and then, at the end of the line, pressing whatever magic key that makes the IDE rewrite it to the actual type so that it compiles.

One of the syntax options in the JEP is "final name = RHS;". When i first saw that i could not understand why anybody in their right mind would even consider a partial solution like that. But now that i wrote about write-time type inference, it starts getting more and more attractive:

A tiny nudge towards immutability, natural "write-time type inference" that is correct until the first nonfinal access is written (IDEs already offer a "make nonfinal?" fix in that case) and nonfinal identifiers will often be a broader type than the RHS assignment anyway.

Re: JEP 286: Local-Variable Type Inference

#38

Post by incepted »

freekh wrote: post #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 when…

> 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.

Type inference has absolutely nothing to do with type safety. Programming languages don't become more or less statically type safe depending on whether they support type inference.

Type inference only enables to omit type annotations in certain parts of your code. Your values are just as typed as if you had used that type annotation.

As for the original point you were trying to make, I would say Scala is no more type safe than Java. They are about on par in how they allow unsafe expressions to type check. Scala's type system is certainly richer than Java's, but that's a separate point (and maybe the one you were trying to make).

> 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.

Absolutely not.

Omitting a type in your source doesn't remove the type from that variable. The code is exactly as typed with that type annotation as it is without.

Re: JEP 286: Local-Variable Type Inference

#40

Post by ygra »

dloose wrote: post #30
pdpi wrote: post #25

Earlier quoted context omitted.

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.

C# shows pretty compellingly that adding features does not have to break existing code. For example, you can use every keyword added after 1.0 as identifier, too.
Post reply on HN