JAX enter: How do you feel about the new six-month cycle and the new rhythm? After all, Java 10 was the fastest release in Java’s 23-year history and now we’re already 2 months away from Java 11.

I love it! Java is up there as one of the most sophisticated open source (or otherwise) software projects out there. It’s an virtual operating system in what it gives us. It powers one of the largest communities of applications and a dozen other satellite industries. It is up there with COBOL as being one of the languages that most empowered organizations to deliver value, and profit. Java is an _amazing_ piece of kit, and I’d still be grateful even if it didn’t come out every six months. After all, Java is that it is the host for _other_ languages, like Groovy, Scala, Clojure, JRuby, and Kotlin. So, if Java doesn’t have your favorite language feature, surely one of those (or many other) languages will. That said, releasing software early and often results in _better_ software. It’s a good way to integrate feedback, to stay agile. (Thank you, Java!)

JAX enter: Do you think the new release cadence will lead to fatigue or is it just keeping developers on their toes?

The new release cycle is two-tiered. There are long term releases, like Java 8 and Java 11, where organizations weary of instability can park their applications for a few years and enjoy stability and support. For the rest of us, we’re free to upgrade to the latest and greatest and enjoy the steady trickle of new features.

JAX enter: Describe your favorite Java 11 feature.

Raw String literals which give me multiline Strings and methods to support them, like `repeat()` and `stripLeading()`. This is ideal for text processing.

JAX enter: Java 11 will be “lighter” in the sense that JavaFX will soon be decoupled from the JDK, we’re saying goodbye to Java EE modules and Nashorn JavaScript engine will be deprecated. What’s left to axe?

Good question! I haven’t given it so much thought. I don’t use AWT/Swing a lot. So, maybe them? But would those benefit from extracted and developed in isolation? I’m not so sure… I’m happy now that the CORBA modules are gone.

JAX enter: A lot of developers are still using Java 8. What does this mean for Java 11 adoption? Do you think Java 11 will be important or big enough to make them want to drop Java 8?

I think so. A lot of organizations have parked their old applications at Java 8 because it’s supported. Java 11 rolls up all the interesting features in earlier releases and represents a reasonable place to replatform, assured in the stability of the release for a while.

JAX enter: Speaking of Java 8, public updates will remain available for individual, personal use through at least the end of 2020 but business users won’t be that lucky — the ‘public updates’ tap will be turned off in January 2019. A lot of Java developers believe that this decision is “ruining Java”. What’s your take on that?

Java 8 was released in 2014 and resources are finite. I don’t think it’s reasonable to expect that old iteration of software be supported in perpetuity. We on the Spring team release new releases all the time and try to be as accommodating as possible in supporting older iterations. At some point, you just have to hope people will see value in what you do and upgrade. No single change in any recent release of Java threatens the stability of your production application. Sure, there are some issues that will take a solid ten to fifteen minutes of Googling, but they’re solvable and well-understood problems.

JAX enter: Nashorn JavaScript engine will soon be deprecated and the most viable alternative seems to be GraalVM. What does GraalVM have that Nashorn doesn’t? Should Nashorn be kept alive by the community?

I hope Nashorn should be kept alive by the community, but I don’t know that it will. JavaScript is by any measure one of the most prolific languages and yet Nashorn hasn’t thrived, even under Oracle. Developing a language is hard and depends on specialized skills. It is not the work of the commons. There are very few enthusiastic and talented folks, like JRuby’s Charles Nutter, doing the work for the love of the work. Graal is an exciting horizon! I’m experimenting with it and they’re advancing by leaps and bounds. I’m particularly a fan of the language interop under the same platform and the native image builder.

JAX enter: How do you feel about ZGC? Can it make latency a non-issue for Java applications?

What’s not to love? There have been a lot of use-cases over the years that would lend themselves to this GC. Big data and online transactional systems come to mind. We’ve seen interesting developments, like off-heap memory for various data grid technologies and the remarkable work of Azul’s Java virtual machine in supporting large heaps, that could perhaps benefit from ZGC.

JAX enter: Demand is growing for serverless platforms. Will serverless begin a major reshaping of Java?

I sure hope so! At Pivotal, we have a function-as-a-service platform [called Project Riff](http://ProjectRiff.io). It’s an open-source, Apache 2 licensed, function-as-a-service platform that is built on Kubernetes and the just announced KNative technology, on which Google and Pivotal have collaborated. We also have Spring Cloud Function, which lets you write code that is agnostic of any one function-as-a-service platform and deploy it using adapters. Spring, with its annotation- and POJO-centric component model, means that writing functions is about as concise as you can get in Java. It could be as simple as a class with one method returning a `java.util.Function<I,O>` instance. Or even just a class that implements `java.util.Function<I,O>`. And yet, such an application is a handful of lines larger than the equivalent Node.js application and it starts up a little slower. It’s much slower than the equivalent Go application. So, is this a problem? I don’t think so. I think discussions of serverless, or of scale-to-zero platforms, as being about having an opinionated operational pattern. It is an even further specialized iteration of platform-as-a-service. That is, the value of the platform is not that we can scale to zero and save the “cost” of running a single instance of the application. Most orgs can afford the cheap instance prices on public cloud infrastructure these days. Instead, serverless is about optimizing for organizational agility; how quickly can I get this job that sends emails, resizes images, or runs a report up and running and responding to trigger events? With a platform like Project Riff, it turns out, really quickly! And, all this while being able to integrate with the the rest of the Java ecosystem. In this light, I think serverless is already reshaping Java, and its building upon the evolutions inspired by the recent trends towards cloud-native applications. It’s building upon the operational insight we understood in moving to cloud native architectures.

JAX enter: What features would you like to see in Java 12?

I’m keen on Project Loom, which supports fibers and continuations on the JVM. I’m not sure when that is slated for release, though.