News could hardly get more exciting than this, for a programming language aficionado!
There is now a JEP 286 for Local-Variable Type Inference with status “Candidate”. And a request for feedback by Brian Goetz, which I would love to invite you to participate in: http://mail.openjdk.java.net/pipermail/platform-jep-discuss/2016-March/000037.html
Please do so, the survey remains open only from March 9 to March 16!
This is not a feature that will be implemented. It might be implemented. Hence, there is no specific Java version yet, which is why I name the Java version “A” (for Awesome).
What is local-variable type inference and why is it good?
Let’s have a look at a feature that various other languages have had for quite a while. In this blog post, I’d like to discuss the general idea, not the possibly specific implementation that might be planned for Java, as that would be too early, and I certainly don’t have the big picture of how this fits into Java.
In Java, as well as in some other languages, types are always declared explicitly and verbosely. For instance, you write things like:
// Java 5 and 6 List<String> list = new ArrayList<String>(); // Java 7 List<String> list = new ArrayList<>();
Notice how in Java 7, some syntax sugar was added via the useful diamond operator <>. It helps removing unnecessary redundancy in the Java way, i.e. by applying “target-typing”, which means the type is defined by the “target”. Possible targets are:
- Local variable declarations
- Method arguments (both from the outside and from the inside of the method)
- Class members
Since in many cases, the target type MUST be declared explicitly (method arguments, class members), Java’s approach makes a lot of sense. In the case of local variables, however, the target type doesn’t really need to be declared. Since the type definition is bound to a very local scope, from which it cannot escape, it may well be inferred by the compiler without the source code ever being explicit about it, from the “source type”. This means, we will be able to do things like:
// Java A as suggested in the JEP // infers ArrayList<String> var list = new ArrayList<String>(); // infers Stream<String> val stream = list.stream();
In the above example var stands for a mutable (non-final) local variable, whereas val stands for an immutable (final) local variable. Notice how the type of list was never really needed, just as when we write the following, where the type is already inferred today:
stream = new ArrayList<String>().stream();
This will work no different from lambda expressions, where we already have this kind of type inference in Java 8:
List<String> list = new ArrayList<>();
// infers String
list.forEach(s -> {
System.out.println(s);
};Think of lambda arguments as local variables. An alternative syntax for such a lambda expression might have been:
List<String> list = new ArrayList<>();
// infers String
list.forEach((val s) -> {
System.out.println(s);
};Other languages have this, but is it good?
Among these other languages: C# and Scala and JavaScript, if you will ;). YAGNI is probably an common reaction to this feature. For most people, it’s mere convenience to be able not to type all types all the time. Some people might prefer to see the type explicitly written down, when reading code. Especially, when you have a complex Java 8 Stream processing pipeline, it can get hard to track all the types that are inferred along the way. An example of this can be seen in our article about jOOλ’s window function support:
BigDecimal currentBalance = new BigDecimal("19985.81");
Seq.of(
tuple(9997, "2014-03-18", new BigDecimal("99.17")),
tuple(9981, "2014-03-16", new BigDecimal("71.44")),
tuple(9979, "2014-03-16", new BigDecimal("-94.60")),
tuple(9977, "2014-03-16", new BigDecimal("-6.96")),
tuple(9971, "2014-03-15", new BigDecimal("-65.95")))
.window(Comparator
.comparing((Tuple3<Integer, String, BigDecimal> t)
-> t.v1, reverseOrder())
.thenComparing(t -> t.v2), Long.MIN_VALUE, -1)
.map(w -> w.value().concat(
currentBalance.subtract(w.sum(t -> t.v3)
.orElse(BigDecimal.ZERO))
));The above implements a running total calculation that yields:
+------+------------+--------+----------+ | v0 | v1 | v2 | v3 | +------+------------+--------+----------+ | 9997 | 2014-03-18 | 99.17 | 19985.81 | | 9981 | 2014-03-16 | 71.44 | 19886.64 | | 9979 | 2014-03-16 | -94.60 | 19815.20 | | 9977 | 2014-03-16 | -6.96 | 19909.80 | | 9971 | 2014-03-15 | -65.95 | 19916.76 | +------+------------+--------+----------+
While the Tuple3 type needs to be declared because of the existing Java 8’s limited type inference capabilities (see also this article on generalized target type inference), are you able to track all the other types? Can you easily predict the result? Some people prefer the short style, others claim:
@lukaseder I always declare my types in Scala. I really don't think this adds anything to Java's game beyond syntactic sugar.
— Steve Chaloner (@steve_objectify) March 10, 2016
On the other hand, do you like to manually write down a type like Tuple3<Integer, String, BigDecimal>? Or, when working with jOOQ, which of the following versions of the same code do you prefer?
// Explicit typing
// ----------------------------------------
for (Record3<String, Integer, Date> record : ctx
.select(BOOK.TITLE, BOOK.ID, BOOK.MODIFIED_AT)
.from(BOOK)
.where(TITLE.like("A%"))
) {
// Do things with record
String title = record.value1();
}
// "Don't care" typing
// ----------------------------------------
for (Record record : ctx
.select(BOOK.TITLE, BOOK.ID, BOOK.MODIFIED_AT)
.from(BOOK)
.where(TITLE.like("A%"))
) {
// Do things with record
String title = record.getValue(0, String.class);
}
// Implicit typing
// ----------------------------------------
for (val record : ctx
.select(BOOK.TITLE, BOOK.ID, BOOK.MODIFIED_AT)
.from(BOOK)
.where(TITLE.like("A%"))
) {
// Do things with record
String title = record.value1();
}I’m sure that few of you would really like to explicitly write down the whole generic type, but if your compiler can still remember the thing, that would be awesome, wouldn’t it? And it’s an opt-in feature. You can always revert to explicit type declarations.
Edge-cases with use-site variance
There are some things that are not possible without this kind of type inference, and they’re related to use-site variance and the specifics of generics as implemented in Java. With use-site variance and wild cards, it is possible to construct “dangerous” types that cannot be assigned to anything because they’re undecidable. For details, please read Ross Tate’s paper on Taming Wildcards in Java’s Type System.
Use-site variance is also a pain when exposed from method return types, as can be seen in some libraries that either:
- Didn’t care about this pain they’re inflicting on their users
- Didn’t find a better solution as Java doesn’t have declaration-site variance
- Were oblivious to this issue
An example:
interface Node {
void add(List<? extends Node> children);
List<? extends Node> children();
}Imagine a tree data structure library, where tree nodes return lists of their children. A technically correct children type would be List<? extends Node> because the children are Node subtypes, and it is perfectly OK to use a Node subtype list.
Accepting this type in the add() method is great from an API design perspective. It allows people to add a List<LeafNode>, for instance. Returning it from children() is horrible, though, because the only options are now:
// Raw type. meh List children = parent.children(); // Wild card. meh List<?> children = parent.children(); // Full type declaration. Yuk List<? extends Node> children = parent.children();
With JEP 286, we might be able to work around all of this and have this nice fourth option:
// Awesome. The compiler knows it's // List<? extends Node> val children = parent.children();
Conclusion
Local Variable Type Inference is a hot topic. It’s entirely optional, we don’t need it. But it makes a lot of things much much easier, especially when working with tons of generics. We’ve seen that type inference is a killer feature when working with lambda expressions and complex Java 8 Stream transformations. Sure, it will be harder to track all the types across a long statement, but at the same time, if those types were spelled out, it would make the statement very unreadable (and often also very hard to write).
Type inference helps make developers more productive without giving up on type safety. It actually encourages type safety, because API designers are now less reluctant to expose complex generic types to their users, as users can use these types more easily (see again the jOOQ example).
In fact, this feature is already present in Java in various situations, just not when assigning a value to a local variable, giving it a name.
Whatever your opinion is: Do make sure to share it to the community and answer this survey: http://mail.openjdk.java.net/pipermail/platform-jep-discuss/2016-March/000037.html
Looking forward to Java A where A stands for Awesome.
| Reference: | Java A’s new Local-Variable Type Inference from our JCG partner Lukas Eder at the JAVA, SQL, AND JOOQ blog. |
