Brian Goetz - Stewardship: the Sobering Parts

Programming language design is not just about type theory and grammars. For evolving a mature programming language like Java, it is about finding ways to add capabilities while maintaining compatibility, both with existing code and with the expectations and mental models of 9 million or so Java developers. In this talk, Java Language Architect Brian Goetz looks at some of the challenges and lessons of steering Java through major evolutionary changes, and a sneak peek at where the Java platform is headed.

Brian Goetz is one of the leading authorities on the Java platform. He is the author of the very successful 'Java Concurrency in Practice', and has published over 75 articles on software 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.

[eshgholah]

Brian has an extremely funny side. He has both intelligence and humour. 

[migueljimenezZ]

Quick question: in 32:20 the method implemented in line 2 is incorrect right? shouldn't it be actionPerformed? (Just to be sure)

[lukas_eder]

Really interesting talk showing why Java is still #1

[olivierdeclercq]

Cool talk Brian! Very informative for me. Brussels #leprésalé likes! Hope you enjoyed your stay

[Collaborologist]

We have to stop putting developers into a situation where they have to choose been good abstraction vs good performance

[jonaskoelker]

The most interesting part from my perspective was Goetz's brief remark about OO vs. FP: OO is about abstracting over data, FP is about abstracting over behavior.

I think it's easier to emulate OO in FP (as defined by Goetz) than the other way around: to abstract over data, write a function that gets the data. To abstract over behavior, write an interpreter for some abstract syntax tree or bytecode?

For example, let's say you have two sets of integers, one represented by an AVL tree and the other by a red-black tree, and you want consumers to simply say "give me all the elements".

implement avlToList and rbToList, then either:
- using parametric polymorphism, write consumers to take a (t, t -> ListOf Int) instead of just a tree.
- using ad-hoc polymorphism, define a ToListAble interface and implement it for AVL and RB trees using the two xToList methods.

To abstract over behavior using data (and abstractions over data), maybe I'm just drawing a blank but the best I can come up with is some kind of "code is data": interpret an AST or some bytecode. It's not obvious to me how data abstraction helps, here, and I'm pretty damn sure it's not the kind of code I want to write. Greenspun's 10th rule also says hi.

Coming to think about it, what _is_ data abstraction? I think what that means is that you have some interface-level data, like a sequence of elements and/or a way of iterating through them, and some data—the nodes of an AVL or red-black tree—plus some way for a data consumer to work with the interface-level data when being handed a particular representation.

For that to be worth anything*, the consumer must be able to abstract over the behavior which maps between the interface and representation level of the data; otherwise the consumer is coupled to the internal representation, in the sense that in any running program it can only work with one representation. I guess you can switch out all the AVL trees with red-black trees or vice versa by modifying your source code and recompiling, so okay, something* is gained but not much IMO.

Maybe one objection one can level about my central claim is that what I'm doing is really building a data abstraction technique using functional parts. In that case, my claim is this: it's way easier to build data abstraction out of the ingredients of almost any modern functional language than it is to build behavior abstraction out of raw data.

Maybe an objection against the division is that data abstraction, translating between internal and interface representation, inherently is a behavior and thus data abstraction presupposes or is a form of behavior abstraction and the distinction blurs together. Very well; since you often need behavior abstraction both for data abstraction and for other purposes, a good design makes behavior abstraction easy to work with. General behavior abstraction should be the focus, since you can do data abstraction as a special case application of those general tools.

[Collaborologist]

If you don't know the right way, at least don't do the wrong way. And sometimes that means doing nothing. And that's OK.

[FellshardYT]

While I completely agree with your conclusions when it comes to development of the JVM and the Java bytecode, there's a bit of a shell game you play with languages: you present a false dichotomy of either changing the language slowly and steadily or throwing away the language entirely.

The recent boom in the number of JVM languages demonstrates that sometimes, the language itself cannot work with and present the underlying abstractions in a way that is feasible or practical. At that point, are you willing to simply set aside the current language, allow it to settle in as its own stable entity that can still be used for years, and start anew with a fresh ecosystem that isn't bound by those same assumptions and shackles?

Part of the problem that people have with Java at this point is that they know that the language is a hindrance in expressing many of the modern concepts developers work with. There's a whole ecosystem of libraries and language features that lock into this older mentality, leaving us with no option but to pine for something better. At some point, COBOL simply faded away, slowly. It wasn't trashed or burned, it was simply subsumed by alternatives that were able to better represent the problems being modeled.

At what point should Java simply say, "This is sufficient, and our time is better spent creating the next foundational platform?" Maybe you can reuse the JVM, maybe not. But trying to stretch a tool that is already tearing at the seams is naive at best, and catastrophic at its worst. Plan to move towards the next big tool, instead of simply assuming everything must be built with current libraries. If you don't plan, people will eventually simply leave, or craft their own alternatives. Take a look at Kotlin, which has effectively - and simply - added many features you discussed in this talk, targeting Java 1.6. This is an example of a tool, unbound by many of Java's frustrations, with full compatibility with existing Java software. I believe their example could serve the JVM universe well in coming years.

[Collaborologist]

There's not such thing as "just one exception"

[birthdayforfrances]

I can't help thinking that if other fields worked this way we'd still be building houses with mud and sticks. Maybe this year we'd have mud with ever-so-slightly bigger sticks. Or mud with a tiny bit more clay in it. But still: mud and sticks.

Further, the argument from number of users is rather circular, isn't it? "I emply 300 monks transcribing books with ink and quill pen. We can't move to a printing press! It's an unfamiliar paradigm to them! The fact that I employ so many monks is testament to the leverage of my technical decisions! If we moved to a printing press, I would employ far fewer."

Uh, yeah. This is why java market share has been plunging: business has realized it can deliver better product at dramatically lower cost by staying far, far away.