What’s available?

The appengine-java-standard repository contains the Java source code for the Java standard environment, the production runtime, the APIs, and the local SDK.

Zooming on the various directories of the project, you’ll find the APIs from the com.google.appengine.api package for using and accessing App Engine services like Datastore to store your data, Blobstore to save your binary blobs, Taskqueue to enqueue computing tasks, Memcache to cache expensive results you don’t want to recompute, or Urlfetch to call external services.

The great developer experience of Google App Engine comes in part from the fact you can run your application locally on your development machine, thanks to the local development environment. The aforementioned services all have a local implementation enabling you to start your app on your machine, rather than having to deploy in the cloud each time you make a change.

To use the services in the cloud, however, you can use Google’s built-in remote APIs (code) that let you transparently access App Engine services from any Java application. For example, you can use the Remote API to access a production Datastore from an app running on your local machine. You can also use Remote API to access the Datastore of one App Engine application from a different App Engine application.

In the runtime folder, you’ll be able to see how your App Engine app is started, with the underlying Jetty servlet container, and understand how the various components or services are configured on startup.

What’s not open source today are the specific layers that tie App Engine to the underlying Borg cluster management system, internal to the Google infrastructure, as developers can’t replicate the whole Google backend easily in their own environment.

Why make it open source?

It’s important for our customers to not be locked in a particular tool, environment, or vendor, and give them the liberty to run their workloads elsewhere, and understand how we actually run their code. That’s why Google Cloud follows an Open Cloud approach, and participates actively in the open source ecosystem. Our open cloud approach enables you to develop software faster, innovate more easily, and scale more efficiently—while also reducing technology risk. Through the years, we’ve open sourced various technologies, like Kubernetes, based on our experience of running containers at scale, or the gVisor sandbox, an application kernel for containers that provides efficient defense-in-depth anywhere, and which was pioneered by the App Engine environment, as gVisor was its sandbox environment.

By open sourcing the App Engine Java runtime, we’re making the first step towards letting you run the whole App Engine environment wherever you want: on your local development environment, on-premise in your own data center, or potentially on our other computing platforms like Cloud Run. We’re also making a key step towards easier transitions for future runtimes based on newer Long-Term Support versions of the Java programming language.

Finally, being able to compile, test and release the Java runtime environment for Java 8, Java 11 and soon Java 17 from an open source platform is much easier than relying on the huge internal Google mono repository system which is intended to support only one single version of everything, including a single JDK toolchain. We are releasing the binary artifacts in the Maven central repository, including Javadocs and sources to find the relevant code regarding exceptions raised during runtime execution.

Going further

If you’re not familiar with App Engine yet, be sure to check out our online resources about this powerful and scalable serverless application platform on our website. And get started with the tutorials on the Java 8 or Java 11 standard environment. To learn more about this open source App Engine Java runtime, please visit our repository on Github, to discover how the serverless secret sauce is made. And if you’re feeling like helping and contributing, we’re looking forward to hearing from you, by filing new tickets or by preparing some pull requests.