Interview series with Java influencers — Final part

What does it take for Java to compete in the serverless space?

Gabriela Motroc
JDK 12
© Shutterstock/ Hyejin Kang

End of the line for our Java influencers interview series! In the last part of the series, we discuss the feature(s) our Java influencers would like to see in JDK 12, as well as the role of serverless in Java’s future.

JDK 12 patrol

JDK 11 is almost upon us but that’s no excuse to sit around and do nothing! The work on JDK 12 has begun and we’re keeping track of everything that’s going live. And since JDK 11 will be featuring 3 JEP contributions from the community (the largest number of community contributions to a release so far), let’s see if we can top that!

We want to know what features our seven Java influencers would like to see in JDK 12 and perhaps compare the answers with the wishlist for previous releases. Just to give you a flavor of what’s included in our interviewees’ wishlist, projects Loom and Valhalla, as well as GraalVM have a lot of fans.

Since this is the final part of our interview series, we’re also talking about Java’s focus on the serverless space (see Project Fn). We briefly talked about this last year but now it’s time to dive deeper into this topic.

Just to freshen up your memory, this is what Oracle’s Mike Lehmann told us in 2017:

Oracle sees serverless as a natural next step from where the industry has gone from app server centric models to containers and microservices and more recently with serverless. Serverless is all about building applications without having to be concerned with the underlying infrastructure of compute, storage and networking — it is focused on the developer simply writing code for their application and the underlying cloud runtime taking care of these external resource concerns.



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

Meet the Influencers

Markus Eisele (@myfear) is the Director of Developer Advocacy at Lightbend and a Java Champion.

Guillaume Laforge (@glaforge) is Developer Advocate for Google Cloud Platform, Apache Groovy PMC Chair at The Apache Software Foundation and Java Champion.

Lukas Eder (@lukaseder) is the founder and head of R&D at Data Geekery GmbH, the company behind jOOQ and a Java Champion.

Josh Long (@starbuxman) is the Spring Developer Advocate at Pivotal. He is the author of 5 books and 3 best-selling video trainings. He is also a Java Champion.

Eberhard Wolff (@ewolff) is a Fellow at INNOQ and a software architect.

Martin Thompson (@mjpt777) is a consultant, trainer, and coach specializing in designing high-performance and low-latency systems. He is also a Java Champion.

Quentin Adam (@waxzce) is the CEO of Clever Cloud.

Markus Eisele: Generally speaking, this is another polyglot world that is less about the programing language used and more about the developer productivity that is available. Oracle is pushing the Fn project here but there are plenty of other alternatives to explore.

The more general direction of the industry is to cut smaller services which can be run independently. That implies that Java will need better startup qualities and could use improvements in its JIT mechanisms. The newly introduced projects like Graal and ZGC are starting to address this field from an infrastructure perspective. We’ll see how much more can and will have to be done and how Java as a programming language finds the balance between the maturity and stability it provides so far and the innovative innovation cycles we are facing right now.

Having something like scripts you run in JShell be seen as functions for Function-as-a-Service solutions could be cool instead of having to create Java classes with single public methods in them.

Guillaume Laforge: 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.

Lukas Eder: By serverless, you mean the fancy new name for stored procedures? No. They have always existed, nothing will be reshaped by them.

Josh Long: I sure hope so! At Pivotal, we have a function-as-a-service platform called Project Riff. 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>`.

SEE ALSO: Meet Helidon, a new open source Java microservices framework

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 organizations 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 rest of the Java ecosystem. In this light, I think serverless is already reshaping Java, and it’s 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.

SEE ALSO: Introducing Fn: “Serverless must be open, community-driven, and cloud-neutral”

Java will be a much better fit for serverless in the future – and that is great news.

Eberhard Wolff: Serverless has different requirements. The code is launched on demand so startup time is important. The JVM’s JIT compiler is optimized for a system that runs for a long period of time. Over time, the JIT will compile more and more of the code to machine language and introduce other optimizations. This does not pay off with serverless at all.

Also, the memory consumption is more important with serverless as more memory increases costs. Some of Java’s garbage collection algorithms consume quite a lot of memory. I thought these problems are so fundamental that they cannot be solved. However, the GraalVM compiles the code ahead of time to machine code and reduces startup time significantly. So it seems that Java will be a much better fit for serverless in the future – and that is great news!

Martin Thompson: To compete in the Serverless space, Java will have to improve its startup time and footprint. Work is being done in the area but it has a long way to go when competing with footprint and startup time of other languages.

SEE ALSO: “GraalVM’s ambitions are much broader than those of Nashorn”

Quentin Adam: Serverless is more of a trend for conference and blog articles than a new way to build software, and as I explained in my article, FaaS today is more the return of proprietary application servers, with more limitation than expected.

But if you look at the serverless’ meaning, people want to get rid of server management (and not servers, who are still running software), and it’s the core principle of PaaS to deploy stuff and manage it automatically. From a Java perspective, there is nothing to do here, some people will begin to create new framework or platform on top of Java with a serverless branding, that’s great, but I see nothing to do to make it easier, and I do not think it has to be a focus.


What features would you like to see in Java 12?

Markus Eisele: I’m still eagerly monitoring the progress of project Valhalla which would be a great addition. Of course, Graal as the new standard JIT compiler would be amazing.

Guillaume Laforge: 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.

GraalVM is a very important new technology. So that is pretty high on my wishlist.

Lukas Eder: JEP 326! It’s a game changer for people who like to embed external DSLs into Java (oh, say, SQL, XML, JSON, CSV, JavaScript, Regular expressions, XPath, you name it)

Josh Long: 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.

Eberhard Wolff: I think GraalVM is a very important new technology. So that is pretty high on my wishlist. However, the JDK Enhancement Proposals for Java 12 don’t include the GraalVM and it might actually stay a separate project.

Martin Thompson: Most systems are now distributed and thus network comms are an important feature. We are getting some progress with project Loom but I feel this is the wrong strategic direction. Most application developers use a library when making network calls so they don’t use the networking APIs directly. The library developers of messaging and comms systems are crying out for better NIO libraries to use the latest features like DPDK or more direct integration with Windows or Linux APIs. Networking library developers are comfortable with non-blocking APIs and don’t need this to be hidden from them.

SEE ALSO: ZGC: Making Java a more attractive platform for a wider set of applications

In addition, Serverless suggests event-driven designs which are triggered from the network. This feels like an overlooked area for Java.

Pattern matching: this feature is really interesting, leading to more readable code. It’s a good solution to avoid errors on cascading if/else, allow the compiler to detect uncovered options, it will be a really good addition to Java.

Quentin Adam: For Java as a language, I see two main points:

  • Try to make it less verbose, maybe integrate more project Lombok ideas, with optional getter/setter (autogenerate it at compilation), this will be a good solution to reduce boilerplate code in our codebase.

For Java as a platform, I really hope for more work on the WebAssembly compilation to be able to use JVM/Java codebase on the browser and the blockchain.


17 features for JDK 11

Just to freshen up your memory, JDK 11 includes the following features:

181: Nest-Based Access Control

Introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language. Nests allow classes that are logically part of the same code entity, but which are compiled to distinct class files, to access each other’s private members without the need for compilers to insert accessibility-broadening bridge methods.

309: Dynamic Class-File Constants

Extend the Java class-file format to support a new constant-pool form, CONSTANT_Dynamic. Loading a CONSTANT_Dynamic will delegate creation to a bootstrap method, just as linking an invoke dynamic call site delegates linkage to a bootstrap method.

315: Improve Aarch64 Intrinsics

Improve the existing string and array intrinsics, and implement new intrinsics for the java.lang.Math sin, cos and log functions, on AArch64 processors.

318: Epsilon: A No-Op Garbage Collector

Develop a GC that handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down.

320: Remove the Java EE and CORBA Modules

Remove the Java EE and CORBA modules from the Java SE Platform and the JDK. These modules were deprecated in Java SE 9 with the declared intent to remove them in a future release.

321: HTTP Client (Standard)

Standardize the incubated HTTP Client API introduced in JDK 9, via JEP 110, and updated in JDK 10.

323: Local-Variable Syntax for Lambda Parameters

Allow var to be used when declaring the formal parameters of implicitly typed lambda expressions.

324: Key Agreement with Curve25519 and Curve448

Implement key agreement using Curve25519 and Curve448 as described in RFC 7748.

327: Unicode 10

Upgrade existing platform APIs to support version 10.0 of the Unicode Standard.

328: Flight Recorder

Provide a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM.

329: ChaCha20 and Poly1305 Cryptographic Algorithms

Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a relatively new stream cipher that can replace the older, insecure RC4 stream cipher.

330: Launch Single-File Source-Code Programs

Enhance the java launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of “shebang” files and related techniques.

331: Low-Overhead Heap Profiling

Provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI.

332: Transport Layer Security (TLS) 1.3

Implement version 1.3 of the Transport Layer Security (TLS) Protocol.

333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)

The Z Garbage Collector, also known as ZGC, is a scalable low-latency garbage collector.

335: Deprecate the Nashorn JavaScript Engine

Deprecate the Nashorn JavaScript script engine and APIs, and the jjs tool, with the intent to remove them in a future release.

336: Deprecate the Pack200 Tools and API

Deprecate the pack200 and unpack200 tools, and the Pack200 API in java.util.jar.

Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Inline Feedbacks
View all comments