The final day of JavaOne 2014 saw an extended Community Keynote, with technical material that had been omitted from the main keynote. Since then, the ideas presented there have been expanded on considerably. InfoQ caught up with Oracle's Brian Goetz (Java Language Architect) and John Rose (JVM Architect) for a deep-dive discussion on some of the technologies and features being discussed for Java 9 and beyond.
InfoQ: In the JavaOne keynote, you drew a distinction between reification of generics versus primitive specialisation of generic types. That is, making the value of the type parameter available at runtime versus allowing collections of primitive types (such as ArrayList<int>
Goetz: People have quite an emotional distaste for type erasure, it seems to have this "dirty smelly feel". It's actually quite a practical technique and the set of problems it actually causes is pretty small.
Boxing is inefficient; it uses more memory, undermines locality, and puts pressure on the garbage collector. It's great that ArrayList<T>can abstract across different Ts, but its not so great that the user has to suffer the pain of boxing to get the nice abstraction generics gives us when all they want is a list of ints.
InfoQ: What about erased forms of interfaces which have lost information, such as overloads? I mean, you're not going to be able to have List<String>
Goetz: List<String>
A full-blown heterogeneous translation of generics, such as that provided by C++ templates, would map each of these types to a separate, unrelated class. We're not proposing that. But some instantiations, such as List<int>and List<Integer> have always been different types -- but these two types are represented by the same class at runtime. Erasure prevents us from recovering whether a given List at runtime started out as a List<String> or a List<Integer> before it got erased. , might be represented by a different class than List<String> . That is, the mapping of compile-time types to runtime classes may work differently for primitive and value instantiations of List than for reference instantiations.
Rose: Underlying this is that the equivalent of erased types for value types will show up in bytecode.
Goetz: Put another way, developers who have been used to cheating with raw types or <?> are going to have to learn how to do this properly. As soon as we have specialisation and value types this is all much less forgiving. If you don't really know generics - this is the time to learn. We're already seeing some of this with lambdas, if you look at the Stack Overflow questions, a lot of the "why can't I make lambdas do what I want?" questions are really about an incorrect use of generics which is causing type inference to fail.
InfoQ: Let's talk a bit about the possibility of Optional as a proto-value type.
Goetz: There was potentially some slight optimism about the idea of migrating a Java 8 reference type to a Java 10 value type. Basically, we've laid the groundwork, by indicating that developers must not rely upon certain properties (such as identity checks) necessarily being true for types that may become value types in the future. Whether this migration proves to be doable in practice remains to be seen.
InfoQ: Is the Java Native Runtime dead now with the advent of Project Panama?
Goetz: JNR is now part of the Panama story, but there's a lot more in there than just JNR.
InfoQ: Will there be JSRs for Panama and Valhalla, or technology coming from them? When will we know which Java releases are being target?
Rose: It's best to start a JSR when you've already got an idea of where you're going. The start of JSRs will fall somwhere between knowing which JDK release we're targetting and having a protoype people like.
Goetz: This is similar to lambda, we started early in the OpenJDK project and we started the JSR when we knew what success for the project looked like, and we knew who the experts were, to form the Expert Group for the JSR.
Rose: There is enormous value in JSRs, but we need a good starting point, for many reasons, but especially so that we don't form too early and waste the experts time.
Goetz: We're fortunate in that now all the legal machinery is in place for developing JSRs in OpenJDK, we can develop completely in the open from the start. As to releases, watch the Valhalla repos. Especially watch for little pieces moving across into jdk9 / jdk10 repos - just like we did for lambdas.
InfoQ: Can you speak to some of the projects that are out there regarding new approaches to data access - such as IBM Packed Objects, or Gil Tene's ObjectLayout project?
Rose: Java is 20 now, and people have been complaining about arrays since the start, so perhaps it's no surprise that we're coming to a consensus about what needs to change. A lot of these complaints and projects seem to be convergable to an api for getting to flat data.
It does seem like we're getting to a place where we can start to prototype, and that's what Project Panama is for. IBM have been involved from the start, and there's a special mailing list so IBM VM engineers can participate (there are some IP walls that we've needed to work out, but we think we're there now).
There are a few necessary changes to the language - e.g. value types, but we also have things like the VM thinking that all values are managed, and represented by pointers - both of these assumptions have to be overturned. We think we have a multi-language VM already, well - just wait and see what the future holds.
InfoQ: Hazelcast, among others, have been asking for arrays that support long indicies. Is this possible?
Rose: All the new APIs for data we're working on have long indicies.
Goetz: This is something we're working on, but in terms of new features, this is a very large combinatorial space - sparseness, size, read / write vs read-only vs append. Everyone has different wants, and we need to prioritise.
Rose: There are many degrees of freedom here, like a pizza. The idea is that we don't want to treat "pizza with mushrooms and onions" as a completely separate combination from "pizza with onions and peppers"; that leads to 2^n combinations. Instead, you want to say "pick any toppings". We still need to do some work to define the menu.
One common pattern is application managed slab data off to the side. Users have incremental management costs, so they want to manage data themselves. This leads to large numbers of app-formatted bytes, which leads directly to native access to data.
For more information on Project Panama visit here and for Project Valhalla see this article. Keep up to date with InfoQ's full coverage on Java 9 new features including modularity and more.
About the Interviewees
Brian Goetz has been a professional software developer for more than twenty five years. Brian is the author of the successful ‘Java Concurrency in Practice’, and has written over 75 articles on Java development. He was the specification lead for JSR-335 (Lambda Expressions for the Java Language) and has served on numerous other JCP Expert Groups. Brian is the Java Language Architect at Oracle.
John Roseis lead Engineer of the Da Vinci Machine Project, a part of the Open JDK effort. He is also JSR 292 specification lead, working on new support in the JVM standard for dynamic invocation and related facilities, such as type profiling and improved compiler optimizations.
John has worked on Java technology since 1997 at Sun, contributing widely to functionality and performance of the HotSpot and OpenJDK stack, touching everything from hardware architecture to code generators to libraries to programming languages. Past projects include the design of Java inner classes, the initial port of HotSpot to SPARC, the Unsafe API, and various dynamic, parallel, and hybrid languages, including Common Lisp, Scheme (“esh”), dynamic bindings for C++."