The Value in Project Valhalla

I have been interested in the progress of Project Valhalla for quite a while, but Brian Goetz's recent message "Project Valhalla: Goals" has raised my level of interest. I have frequently enjoyed Goetz's writing because he combines two characteristics I want most in a technical author: he knows the subjects he writes about much more deeply than what he is writing about, but is also able to present these concepts at a level approachable to the rest of us who lack his his depth of knowledge in that area. The mail message "Project Valhalla: Goals" is significant in several ways and is highly approachable; it should be read directly by anyone interested in why Project Valhalla is so exciting. Although I recommend reading the original, approachable message, I collect some of my observations from reading this message in this post.

During my software developer career, regardless of the programming language I am using, I have typically found that most software development consists of a series of trade-offs. It is very common to run into areas where the best performing code is less readable than slower code. This trade-off is, in fact, what leads to premature optimization. The danger of premature optimization is that it is "premature" because it the performance gain achieved by the less readable code is actually not needed and so one is effectively exchanging "more dangerous" or "more expensive" code for an unneeded performance benefit.

In Java, a common trade-off of this type is when using objects. Objects can often be easier to use and are required for use with the highly used standard Java collections, but the overhead of objects can be costly in terms of memory and overhead. Goetz points out in "Project Valhalla: Goals" that Project Valhalla has the potential to be one of those relatively rare situations in which performance can be achieved along with "safety, abstraction, encapsulation, expressiveness, [and] maintainability."

Goetz provides a concise summary of the costs associated with objects and maintaining object identity. From this brief explanation of the drawbacks of maintaining object identity in cases in which it is not needed, Goetz moves to the now expected description of how values types for Java could address this issue. In addition to briefly describing advantages of value types, Goetz also provides some alternate names and phrases for value types that might help to understand them better:

• "Aggregates, like Java classes, that renounce their identity"
• "Codes like a class, works like an int"
• "Faster Objects"
• "Programmable Primitives"
• "Cheaper objects"
• "Richer primitives"

Regarding value types, Goetz writes, "We need not force users to choose between abstraction/encapsulation/safety and performance. We can have both." It's not everyday that we can have our cake and eat it too.

In "Project Valhalla: Goals", Goetz also discusses the goal of "extend[ing] generics to allow abstraction over all types, including primitives, values, and even void." He uses examples of the JDK needing to supply multiple methods in its APIs to cover items that are not reference types but must be supported by the APIs because "generics are currently limited to abstracting only over reference types." Goetz points out that even when autoboxing allows a primitive to be used in the API expecting the reference type corresponding to the primitive (such as an int argument being autoboxed to an Integer reference), this boxing comes at a performance cost. With these explanations of the issues in place, Goetz summarizes, "Everyone would be better off if we could write a generic class or method once -- and abstract over all the possible data types, not just reference types." He adds, "Being able to write things once ... means simpler, more expressive, more regular, more testable, more composable libraries without giving up performance when dealing with primitives and values, as boxing does today."

Goetz concludes "Project Valhalla: Goals" with the statement, "Valhalla may be motivated by performance considerations, but a better way to view it as enhancing abstraction, encapsulation, safety, expressiveness, and maintainability -- 'without' giving up performance." I really like Project Valhalla from this perspective: we can get many of the benefits of using objects and reference types while not giving up the performance benefits of using primitives.

Project Valhalla: Goals provides much to think about in a concise and approachable manner. Reading this has increased my interest in Project Valhalla's future and I hope we can see it manifest in the JDK.