Zulu Community

Local-variable type inference

Updated on April 21, 2016 in Community Notes
9 on April 7, 2016

JEP 286 is a proposal to include local-variable type inference in a future version of Java (hopefully JDK 9).  I’ve written a blog post on this and am interested to see what other people think of the possible syntax that will be used and the implications to application development.

  • Liked by
Reply
0 on April 7, 2016

Here’s a link to the blog post.

  • Liked by
Reply
Cancel
0 on April 8, 2016

Looks good for us. 

  • Liked by
Reply
Cancel
2 on April 15, 2016

The suggestion of using var, makes me a bit nervous. It’s clear to me that most programmers can’t even name their statically typed variables by any convention that make their purpose easily understood. But at least i got to know its explicit type, which I would loose by this proposal. Java is already too forgiving for the production of badly written code and needs, in my opinion, to become stricter in these regards.

on April 21, 2016

I think you make a good point.  I suppose the flip-side is that would it be right to deprive more experienced, ‘better’ developers from having a more powerful feature just to limit the mistakes made by those less experienced?

on April 21, 2016

I honestly believe that, for increase of readability, all programmers should be forced to code by the same conventions. Polymorfism is great for implementing a diversity of behaviours by the power of method-overloading, especially in the case where the base class is an abstraction. Even default behaviour can be understandable if the base’s abstraction is made explicit, as it is in Java. So, for the sake of readability, all inheritance should be explicit by the use of abstract base classes. Why not make this a requirement?

Another problem that can arise with polymorfism lies in the overuse of generics where the generic code itself does not convey its purpose, but one must read other parts of the code to understand its meaning.

Just think of the overall disservice to readablility polymorfism can bring. I have coded quite a bit of C++ where I have come in contact with operator overloading. While powerful, the use of it makes the code unintelligible until you learn what its author had in mind. Thankfully, Java does not permit operator overloading, and its reason has always been because of readability.

Well, to all this you could say “That’s what comments are good for; descriping behaviour”. To this I say that the code itself should narrate its own nature and become understandable while being read. A big part of this lies with our datamember’s explicit type and naming convention.

Show more replies
  • Liked by
Reply
Cancel
1 on April 15, 2016

I work in Ada, a strongly typed language and I really love it.  I do not like inference of any type.  It is true that by writing everything explicitly you get redundant code, but that redundancy helps you catching errors already at the compilation stage.

on April 21, 2016

I’m a staunch supporter of static typing; I think dynamic typing is just wrong since computer science is all about logic and things being binary.  A value’s type should be set once and not messed with.  If you need a different type use a different variable of that type.  The idea of this proposal is to reduce the amount of repetitive code required in Java.  It’s a tough call on whether the perceived benefits will outweigh the problems it causes.  Only time will tell.

Show more replies
  • Liked by
Reply
Cancel
1 on April 16, 2016

Looks good from readability prospective but need to watch about casting, autoboxing
and instanceof how it will get handled. Var can also bit tuff to read if code very polymorphic in nature.

on April 21, 2016

I think casting, autoboxing and instanceof will all take care of themselves as the inference will simply replace the explicit definition of a variable’s type.  Types will still be static so everything will work as it does now.

Show more replies
  • Liked by
Reply
Cancel