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.

It goes so fast! As a Java developer, I’m really happy to get new features on a more regular basis, without having to wait 2-3 years to get the much talked about new features.
On the other hand, as an open source developer, it complicates things a bit more in terms of JDK version support for my projects.
The module system, in particular, imposes some challenges in this regard, and we need to accommodate different JDK versions for one single version or branch of our open source projects.
But outside of the impact of JPMS, I think it’s a welcome change, and anyway, we can also target only LTS (long term support) versions as major versions to cope with.

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

At this point, this is too early to tell.
At least, it shows that Java is alive and kicking, so we won’t hear about those rants along the lines of Java is dead!
Furthermore, it’s easier to learn one new feature every 6 months, than having to get used to 6 new big features every 3 years.
It’s easier to adopt novelties with a more regular agenda.

JAX enter: Describe your favorite Java 11 feature.

The most visible feature is certainly the new var syntax for declaring local variables.
I’ve always enjoyed using the “def” syntax in Apache Groovy, so I’m happy to have something similar in Java as well.
Be sure to keep using easily readable and understandable variable names, and it’s gonna be great to be able to just use “var” to declare the variable.

It’s easier to learn one new feature every 6 months, than having to get used to 6 new big features every 3 years”

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

I’m actually not necessarily super happy to see Nashorn go, as it was a nice way to add built-in scripting in a Java app. But so be it, and it’s pretty easy to add other alternative language solutions like Apache Groovy anyway. But it sounded a useful feature to have built-in.
I think Corba should be removed too, which is a good idea, as its usage is rarely seen anymore in the wild these days.
Perhaps ultimately, the AWT / Swing APIs should be moved outside of the JDK, but I’m a bit afraid of the impact, in particular if it means it becomes unmaintained, and then we can’t have nice UI toolkits anymore for client-side applications like IDEs (I’m thinking tools like Eclipse IDEA for example, what’s happening if Swing becomes unbundled, and worse, unmaintained?)

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?

It’s possible that developers and enterprises will stick to Long Term Support versions, and target those versions for their next upgrades, rather than upgrading every 6 months.
At customers’ companies I’ve work with, it was often a big IT decision to move to a newer version of the JDK. However it’s probably less the case as more companies are containerizing their workloads and using the cloud more and more.
So we’ll have to see if the more wide-spread DevOps practices, Cloud Native approaches, also help companies upgrade more rapidly, or if they’ll still stick to a slower upgrade pace.
I don’t have a crystal ball, sorry!

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?

Nashorn and GraalVM are two totally different things. The former is really an embedded language while the latter is a new Java VM kind.
For alternatives to Nashorn, as I mentioned before, there are already variable alternative languages that easy to add to a Java project, such as the Apache Groovy programming language.
GraalVM is definitely an interesting project though, as it promises an easy multi-language integration story. But I’m more interested in the capability of building native images, which gives the ability to have apps starting more quickly, taking less space on disk and in memory.
I’m sad however to see Graal go with a GPL license, which makes it not possible to be used by Apache foundation projects, for example. I wish Oracle changed the license to something like an Apache license for more wide-spread possible usage.

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

For short-lived apps, like small micro-services that should spin up fast and last only for a few seconds, I think it’s a welcoming change.
Java has always had complaints because of it’s slow startup time, and the pauses some GC cycles were imposing, so this should definitely help there.
Of course, this shouldn’t be used for long-running apps, otherwise you’ll quickly run into memory issues.

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

The language itself won’t probably evolve much before of containerization or serverless platforms, but it’s more the VM or JDK that might.
For example in Java 9 and 10, improvements have been implemented for the JVM to understand constraints defined by container control groups (cgroups), the number of CPUs available, actual memory available for the JVM (vs the one of the underlying machine).
Serverless isn’t always running on/in containers, but serverless offerings that do will definitely benefit from those improvements.
At the language level, perhaps having something like scripts you run in JShell be seen as functions for Function-as-a-Service solutions could be cool though, instead of having to create Java classes with single public methods in them. It might be interesting to think further through this idea for more concise function definitions.

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

Without necessarily going as far as making Java a dynamic language… I’d like to see some level of dynamicity added to the language.
I’m thinking in particular about something like a dynamic keyword that would allow developers to easily consume things like JSON payloads, without requiring explicit marshalling/unmarshalling to some object graph. In mind, I have the nice support for XML and JSON that languages like Apache Groovy provides, and that could be supported with such a “dynamic” capability.