Welcome to Google App Engine for Java! With App Engine, you can build web applications using standard Java technologies and run them on Google's scalable infrastructure. The Java environment provides a Java Servlets interface and support for standard interfaces to the App Engine scalable datastore and services, such as JDO, JPA, JavaMail, and JCache. Standards support makes developing your application easy and familiar, and also makes porting your application to and from your own servlet environment straightforward.

1. Introduction
2. Selecting the Java API Version
3. Requests and Domains
4. Requests and Servlets
5. Request Headers
6. Responses
7. The Request Timer
8. The Sandbox
9. Class Loader JAR Ordering
10. The JRE White List
11. No Signed JAR Files
12. Logging
13. The Environment
14. Limits
15. SPDY
16. The Datastore, the Services and the Standard Interfaces
17. Scheduled Tasks
18. Java Tools

Introduction

App Engine runs your Java web application using a Java 7 JVM in a safe "sandboxed" environment. App Engine invokes your app's servlet classes to handle requests and prepare responses in this environment.

The Google Plugin for Eclipse adds new project wizards and debug configurations to your Eclipse IDE for App Engine projects. App Engine for Java makes it especially easy to develop and deploy world-class web applications using Google Web Toolkit (GWT). The Eclipse plugin comes bundled with the App Engine and GWT SDKs.

Third-party plugins are available for other Java IDEs as well. For NetBeans, see NetBeans support for Google App Engine. For IntelliJ, see Google App Engine Integration for IntelliJ. (These links take you to third-party websites.)

This runtime is backward compatible with Java 6, and will run all pre-existing Java applications that do not rely on implementation-specific functionality. The App Engine SDK supports Java 6 and later, and the Java 7 JVM can use classes compiled with any version of the Java compiler up to Java 7.

App Engine uses the Java Servlet standard for web applications. You provide your app's servlet classes, JavaServer Pages (JSPs), static files and data files, along with the deployment descriptor (the web.xml file) and other configuration files, in a standard WAR directory structure. App Engine serves requests by invoking servlets according to the deployment descriptor.

The secured "sandbox" environment isolates your application for service and security. It ensures that apps can only perform actions that do not interfere with the performance and scalability of other apps. For instance, an app cannot spawn threads in some ways, write data to the local file system or make arbitrary network connections. An app also cannot use JNI or other native code. The JVM can execute any Java bytecode that operates within the sandbox restrictions.

If you haven't already, see the Java Getting Started Guide for an interactive introduction to developing web applications with Java technologies and Google App Engine.

In the 1.7.5 release of App Engine, experimental support for Java 7 was added as an optional feature. For more information, see Java 7 Considerations.

Selecting the Java API Version

App Engine knows to use the Java runtime environment for your application when you use the AppCfg tool from the Java SDK to upload the app.

There is only one version of the App Engine Java API. This API is represented by the appengine-api-*.jar included with the SDK (where * represents the version of the API and the SDK). You select the version of the API your application uses by including this JAR in the application's WEB-INF/lib/ directory. If a new version of the Java runtime environment is released that introduces changes that are not compatible with existing apps, that environment will have a new version number. Your application will continue to use the previous version until you replace the JAR with the new version (from a newer SDK) and re-upload the app.

Requests and Domains

App Engine determines that an incoming request is intended for your application using the domain name of the request. A request whose domain name is http://your_app_id.appspot.com is routed to the application whose ID is your_app_id. Every application gets an appspot.com domain name for free.

appspot.com domains also support subdomains of the form subdomain-dot-your_app_id.appspot.com, where subdomain can be any string allowed in one part of a domain name (not .). Requests sent to any subdomain in this way are routed to your application.

You can set up a custom top-level domain using Google Apps. With Google Apps, you assign subdomains of your business's domain to various applications, such as Google Mail or Sites. You can also associate an App Engine application with a subdomain. For convenience, you can set up a Google Apps domain when you register your application ID, or later from the Administrator Console. See Deploying your Application on your Google Apps URL for more information.

Requests for these URLs all go to the version of your application that you have selected as the default version in the Administration Console. Each version of your application also has its own URL, so you can deploy and test a new version before making it the default version. The version-specific URL uses the version identifier from your app's configuration file in addition to the appspot.com domain name, in this pattern: http://version_id-dot-latest-dot-your_app_id.appspot.com You can also use subdomains with the version-specific URL: http://subdomain-dot-version_id-dot-latest-dot-your_app_id.appspot.com

The domain name used for the request is included in the request data passed to the application. If you want your app to respond differently depending on the domain name used to access it (such as to restrict access to certain domains, or redirect to an official domain), you can check the request data (such as the Host request header) for the domain from within the application code and respond accordingly.

If your app uses backends, you can address requests to a specific backend and a specific instance with that backend. For more information about backend addressability, please see Properties of Backends.

Please note that in April of 2013, Google will stop issuing SSL certificates for double-wildcard domains hosted at appspot.com (i.e. *.*.appspot.com). If you rely on such URLs for HTTPS access to your application, please change any application logic to use "-dot-" instead of ".". For example, to access version "1" of application "myapp" use "https://1-dot-myapp.appspot.com" instead of "https://1.myapp.appspot.com." If you continue to use "https://1.myapp.appspot.com" the certificate will not match, which will result in an error for any User-Agent that expects the URL and certificate to match exactly.

Requests and Servlets

When App Engine receives a web request for your application, it invokes the servlet that corresponds to the URL, as described in the application's deployment descriptor (the web.xml file in the WEB-INF/ directory). It uses the Java Servlet API to provide the request data to the servlet, and accept the response data.

App Engine uses multiple web servers to run your application, and automatically adjusts the number of servers it is using to handle requests reliably. A given request may be routed to any server, and it may not be the same server that handled a previous request from the same user.

By default, each web server processes only one request at a time. If you mark your application as thread-safe, App Engine may dispatch multiple requests to each web server in parallel. To do so, simply add a <threadsafe>true</threadsafe> element to appengine-web.xml as described in Using Concurrent Requests.

The following example servlet class displays a simple message on the user's browser.

import java.io.IOException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class MyServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain");
        resp.getWriter().println("Hello, world");
    }
}

Request Headers

An incoming HTTP request includes the HTTP headers sent by the client. For security purposes, some headers are sanitized or amended by intermediate proxies before they reach the application.

The following headers are removed from the request:

• Accept-Encoding
• Connection
• Keep-Alive
• Proxy-Authorization
• TE
• Trailer
• Transfer-Encoding

These headers relate to the transfer of the HTTP data between the client and server, and are transparent to the application. For example, the server may automatically send a gzipped response, depending on the value of the Accept-Encoding request header. The application itself does not need to know which content encodings the client can accept.

Note: Entity headers (headers relating to the request body) are not sanitized or checked, so applications should not rely on them. In particular, the Content-MD5 request header is sent unmodified to the application, so may not match the MD5 hash of the content. Also, the Content-Encoding request header is not checked by the server, so if the client sends a gzipped request body, it will be sent in compressed form to the application.

As a service to the app, App Engine adds some headers:

X-AppEngine-Country

Country from which the request originated, as an ISO 3166-1 alpha-2 country code. App Engine determines this code from the client's IP address.

X-AppEngine-Region

Name of region from which the request originated. This value only makes sense in the context of the country in X-AppEngine-Country. For example, if the country is "US" and the region is "ca", that "ca" means "California", not Canada.

X-AppEngine-City

Name of the city from which the request originated. For example, a request from the city of Mountain View might have the header value mountain view.

X-AppEngine-CityLatLong

Latitude and longitude of the city from which the request originated. This string might look like "37.386051,-122.083851" for a request from Mountain View.

Responses

App Engine calls the servlet with a request object and a response object, then waits for the servlet to populate the response object and return. When the servlet returns, the data on the response object is sent to the user.

App Engine does not support sending data to the client, performing more calculations in the application, then sending more data. In other words, App Engine does not support "streaming" data in response to a single request.

Dynamic responses are limited to 32MB. If a script handler generates a response larger than this limit, the server sends back an empty response with a 500 Internal Server Error status code. This limitation does not apply to responses that serve data from the Blobstore or Google Cloud Storage.

If the client sends HTTP headers with the request indicating that the client can accept compressed (gzipped) content, App Engine compresses the response data automatically and attaches the appropriate response headers. It uses both the Accept-Encoding and User-Agent request headers to determine if the client can reliably receive compressed responses. Custom clients can indicate that they are able to receive compressed responses by specifying both Accept-Encoding and User-Agent headers with a value of gzip. The Content-Type of the response is also used to determine whether compression is appropriate; in general, text-based content types are compressed, whereas binary content types are not.

The following headers are ignored and removed from the response:

• Connection
• Content-Encoding
• Content-Length
• Date
• Keep-Alive
• Proxy-Authenticate
• Server
• Trailer
• Transfer-Encoding
• Upgrade

Headers with non-ASCII characters in either the name or value are also removed. In addition, the following headers are added or replaced in the response:

Cache-Control, Expires and Vary

These headers specify caching policy to intermediate web proxies (such as Internet Service Providers) and browsers. If your script sets these headers, they will usually be unmodified, unless the response has a Set-Cookie header, or is generated for a user who is signed in using an administrator account. Static handlers will set these headers as directed by the configuration file. If you do not specify a Cache-Control, the server may set it to private, and add a Vary: Accept-Encoding header.

If you have a Set-Cookie response header, the Cache-Control header will be set to private (if it is not already more restrictive) and the Expires header will be set to the current date (if it is not already in the past). Generally, this will allow browsers to cache the response, but not intermediate proxy servers. This is for security reasons, since if the response was cached publicly, another user could subsequently request the same resource, and retrieve the first user's cookie.

Content-Encoding

Depending upon the request headers and response Content-Type, the server may automatically compress the response body, as described above. In this case, it adds a Content-Encoding: gzip header to indicate that the body is compressed.

Content-Length or Transfer-Encoding

The server always ignores the Content-Length header returned by the application. It will either set Content-Length to the length of the body (after compression, if compression is applied), or delete Content-Length, and use chunked transfer encoding (adding a Transfer-Encoding: chunked header).

Content-Type

If not specified by the application, the server will set a default Content-Type: text/html header.

Date

Set to the current date and time.

Server

Set to Google Frontend.

If you access your site while signed in using an administrator account, App Engine includes per-request statistics in the response headers:

X-AppEngine-Estimated-CPM-US-Dollars

An estimate of what 1,000 requests similar to this request would cost in US dollars.

X-AppEngine-Resource-Usage

The resources used by the request, including server-side time as a number of milliseconds.

Responses with resource usage statistics will be made uncacheable.

If the X-AppEngine-BlobKey header is in the application's response, it and the optional X-AppEngine-BlobRange header will be used to replace the body with all or part of a blobstore blob's content. If Content-Type is not specified by the application, it will be set to the blob's MIME type. If a range is requested, the response status will be changed to 206 Partial Content, and a Content-Range header will be added. The X-AppEngine-BlobKey and X-AppEngine-BlobRange headers will be removed from the response. You do not normally need to set these headers yourself, as the blobstore_handlers.BlobstoreDownloadHandler class sets them. See Serving a Blob for details.

The Request Timer

A request handler has a limited amount of time to generate and return a response to a request, typically around 60 seconds. Once the deadline has been reached, the request handler is interrupted.

The Java runtime environment interrupts the servlet by throwing a com.google.apphosting.api.DeadlineExceededException. If the request handler does not catch this exception, as with all uncaught exceptions, the runtime environment will return an HTTP 500 server error to the client.

The request handler can catch this error to customize the response. The runtime environment gives the request handler a little bit more time (less than a second) after raising the exception to prepare a custom response.

To find out how much time remains before the deadline, the application can import com.google.apphosting.api.ApiProxy and call ApiProxy.getCurrentEnvironment().getRemainingMillis(). This is useful if the application is planning to start on some work that might take too long; if you know it takes five seconds to process a unit of work but getRemainingMillis() returns less time, there's no point starting that unit of work.

While a request can take as long as 60 seconds to respond, App Engine is optimized for applications with short-lived requests, typically those that take a few hundred milliseconds. An efficient app responds quickly for the majority of requests. An app that doesn't will not scale well with App Engine's infrastructure.

Refer to Dealing with DeadlineExceededErrors for common DeadlineExceededError causes and suggested workarounds.

Backends allow you to avoid this request timer; with backends, there is no time limit for generating and returning a request.

Warning! The DeadlineExceededException can potentially be raised from anywhere in your program, including finally blocks, so it could leave your program in an invalid state. This can cause deadlocks or unexpected errors in threaded code, because locks may not be released. After the request completes, the runtime will terminate the server process, so future requests won't be affected; however, any concurrent requests being handled on the same process will be terminated. This is equivalent to calling Thread.stop on the main thread. For more information, see Why is Thread.stop deprecated?. To be safe, you should not rely on the DeadlineExceededException, and instead ensure that your requests complete well before the time limit (using getRemainingMillis() if necessary).

The Sandbox

To allow App Engine to distribute requests for applications across multiple web servers, and to prevent one application from interfering with another, the application runs in a restricted "sandbox" environment. In this environment, the application can execute code, store and query data in the App Engine datastore, use the App Engine mail, URL fetch and users services, and examine the user's web request and prepare the response.

An App Engine application cannot:

• write to the filesystem. Applications must use the App Engine datastore for storing persistent data. Reading from the filesystem is allowed, and all application files uploaded with the application are available.
• open a socket or access another host directly. An application can use the App Engine URL fetch service to make HTTP and HTTPS requests to other hosts on ports 80 and 443, respectively.
• respond slowly. A web request to an application must be handled within a few seconds. Processes that take a very long time to respond are terminated to avoid overloading the web server.
• make other kinds of system calls.

Threads

A Java application can create a new thread, but there are some restrictions on how to do it. These threads can't "outlive" the request that creates them. (On a backend server, an application can spawn a background thread, a thread that can "outlive" the request that creates it.)

An application can

• Implement java.lang.Runnable; and
• Create a thread factory by calling com.google.appengine.api.ThreadManager.currentRequestThreadFactory()
• call the factory's newRequestThread method, passing in the Runnable, newRequestThread(runnable)

or use the factory object returned by com.google.appengine.api.ThreadManager.currentRequestThreadFactory() with an ExecutorService (e.g., call Executors.newCachedThreadPool(factory)).

However, you must use one of the methods on ThreadManager to create your threads. You cannot invoke new Thread() yourself or use the default thread factory.

An application can perform operations against the current thread, such as thread.interrupt().

Each request is limited to 50 concurrent request threads.

Threads are a powerful feature that are full of surprises. If you aren't comfortable with using threads with Java, we recommend Goetz, Java Concurrency in Practice.

The Filesystem

A Java application cannot use any classes used to write to the filesystem, such as java.io.FileWriter. An application can read its own files from the filesystem using classes such as java.io.FileReader. An application can also access its own files as "resources", such as with Class.getResource() or ServletContext.getResource().

Only files that are considered "resource files" are accessible to the application via the filesystem. By default, all files in the WAR are "resource files." You can exclude files from this set using the appengine-web.xml file.

java.lang.System

Features of the java.lang.System class that do not apply to App Engine are disabled.

The following System methods do nothing in App Engine: exit(), gc(), runFinalization(), runFinalizersOnExit()

The following System methods return null: inheritedChannel(), console()

An app cannot provide or directly invoke any native JNI code. The following System methods raise a java.lang.SecurityException: load(), loadLibrary(), setSecurityManager()

Reflection

An application is allowed full, unrestricted, reflective access to its own classes.

It may query any private members, call the method java.lang.reflect.AccessibleObject.setAccessible(), and read/set private members.

An application can also also reflect on JRE and API classes, such as java.lang.String and javax.servlet.http.HttpServletRequest. However, it can only access public members of these classes, not protected or private.

An application cannot reflect against any other classes not belonging to itself, and it can not use the setAccessible() method to circumvent these restrictions.

Custom Class Loading

Custom class loading is fully supported under App Engine. An application is allowed to define its own subclass of ClassLoader that implements application-specific class loading logic. Please be aware, though, that App Engine overrides all ClassLoaders to assign the same permissions to all classes loaded by your application. If you perform custom class loading, be cautious when loading untrusted third-party code.

Class Loader JAR Ordering

Sometimes, it may be necessary to redefine the order in which JAR files are scanned for classes in order to resolve collisions between class names. In these cases, loading priority can be granted to specific JAR files by adding a <class-loader-config> element containing <priority-specifier> elements in the appengine-web.xml file. For example:

<class-loader-config>
	<priority-specifier filename="mailapi.jar"/>
</class-loader-config>

This places "mailapi.jar" as the first JAR file to be searched for classes, barring those in the directory war/WEB-INF/classes/.

If multiple JAR files are prioritized, their original loading order (with respect to each other) will be used. In other words, the order of the <priority-specifier> elements themselves does not matter.

The JRE White List

Access to the classes in the Java standard library (the Java Runtime Environment, or JRE) is limited to the classes in the App Engine JRE White List.

No Signed JAR Files

App Engine's precompilation isn't compatible with signed JAR files. If your application is precompiled (the default), it can't load signed JAR files. If the application tries to load a signed JAR, at runtime App Engine will generate an exception like

 java.lang.SecurityException: SHA1 digest error for com/example/SomeClass.class
       at com.google.appengine.runtime.Request.process-d36f818a24b8cf1d(Request.java)
       at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:210)
       at java.util.jar.JarVerifier.processEntry(JarVerifier.java:218)
       at java.util.jar.JarVerifier.update(JarVerifier.java:205)
       at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:428)
       at sun.misc.Resource.getBytes(Resource.java:124)
       at java.net.URLClassLoader.defineClass(URLClassLoader.java:273)
       at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:616)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:266)

There are two ways to work around this:

• Strip the JAR's signature; or
• Disable precompilation for the whole application.

Logging

Your application can write information to the application logs using java.util.logging.Logger. Log data for your application can be viewed and analyzed using the Administration Console, or downloaded using appcfg.sh request_logs. The Admin Console can recognize the Logger class's log levels, and interactively display messages at different levels.

Everything the servlet writes to the standard output stream (System.out) and standard error stream (System.err) is captured by App Engine and recorded in the application logs. Lines written to the standard output stream are logged at the "INFO" level, and lines written to the standard error stream are logged at the "WARNING" level. Any logging framework (such as log4j) that logs to the output or error streams will work. However, for more fine-grained control of the Admin Console's log level display, the logging framework must use a java.util.logging adapter.

import java.util.logging.Logger;
// ...

public class MyServlet extends HttpServlet {
    private static final Logger log = Logger.getLogger(MyServlet.class.getName());

    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {

        log.info("An informational message.");

        log.warning("A warning message.");

        log.severe("An error message.");
    }
}

The App Engine Java SDK includes a template logging.properties file, in the appengine-java-sdk/config/user/ directory. To use it, copy the file to your WEB-INF/classes directory (or elsewhere in the WAR), then the system property java.util.logging.config.file to "WEB-INF/logging.properties" (or whichever path you choose, relative to the application root). You can set system properties in the appengine-web.xml file, as follows:

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
    ...

    <system-properties>
        <property name="java.util.logging.config.file" value="WEB-INF/logging.properties" />
    </system-properties>

</appengine-web-app>

The Google Plugin for Eclipse new project wizard creates these logging configuration files for you, and copies them to WEB-INF/classes/ automatically. For java.util.logging, you must set the system property to use this file.

The Environment

All system properties and environment variables are private to your application. Setting a system property only affects your application's view of that property, and not the JVM's view.

You can set system properties and environment variables for your app in the deployment descriptor.

App Engine sets several system properties that identify the runtime environment:

1. com.google.appengine.runtime.environment is "Production" when running on App Engine, and "Development" when running in the development server.

   In addition to using System.getProperty(), you can access system properties using our type-safe API. For example:

   if (SystemProperty.environment.value() ==
       SystemProperty.Environment.Value.Production) {
       // The app is running on App Engine...
   }
   

2. com.google.appengine.runtime.version is the version ID of the runtime environment, such as "1.3.0". You can get the version by invoking the following: String version = SystemProperty.version.get();
3. com.google.appengine.application.id is the application's ID. You can get the ID by invoking the following: String ID = SystemProperty.applicationId.get();

App Engine also sets the following system properties when it initializes the JVM on an app server:

• file.separator
• path.separator
• line.separator
• java.version
• java.vendor
• java.vendor.url
• java.class.version
• java.specification.version
• java.specification.vendor
• java.specification.name
• java.vm.vendor
• java.vm.name
• java.vm.specification.version
• java.vm.specification.vendor
• java.vm.specification.name
• user.dir

Request IDs

At the time of the request, you can save the request ID, which is unique to the request. The request ID can be used later to correlate a request with the logs for that request.

Note: Currently, App Engine doesn't support the use of the request ID to directly look up the related logs.

The following code shows how to get the request ID in the context of a request:

com.google.apphosting.api.ApiProxy.getCurrentEnvironment().getAttributes().get("com.google.appengine.runtime.request_log_id")

Quotas

Google App Engine allocates resources to your application automatically as traffic increases to support many simultaneous requests. However, App Engine reserves automatic scaling capacity for applications with low latency, where the application responds to requests in less than one second. Applications with very high latency (over one second per request for many requests) are limited by the system, and require a special exemption in order to have a large number of simultaneous dynamic requests. If your application has a strong need for a high throughput of long-running requests, you can request an exemption from the simultaneous dynamic request limit. The vast majority of applications do not require any exemption.

Applications that are heavily CPU-bound may also incur some additional latency in order to efficiently share resources with other applications on the same servers. Requests for static files are exempt from these latency limits.

Each incoming request to the application counts toward the Requests limit.

Data sent in response to a request counts toward the Outgoing Bandwidth (billable) limit.

Both HTTP and HTTPS (secure) requests count toward the Requests, Incoming Bandwidth (billable), and Outgoing Bandwidth (billable) limits. The Quota Details page of the Admin Console also reports Secure Requests, Secure Incoming Bandwidth, and Secure Outgoing Bandwidth as separate values for informational purposes. Only HTTPS requests count toward these values.

For more information on system-wide safety limits, see Limits, and the "Quota Details" section of the Admin Console.

In addition to system-wide safety limits, the following limits apply specifically to the use of request handlers:

Limit	Amount
request size	32 megabytes
response size	32 megabytes
request duration	60 seconds
maximum total number of files (app files and static files)	10,000 total 1,000 per directory
maximum size of an application file	32 megabytes
maximum size of a static file	32 megabytes
maximum total size of all application and static files	first 1 gigabyte is free $0.13 per gigabyte per month after first 1 gigabyte

SPDY

App Engine applications will automatically use the SPDY protocol when accessed over SSL by a browser that supports SPDY. This is a replacement for HTTP designed by Google and intended to reduce the latency of web page downloads. The use of SPDY should be entirely transparent to both applications and users (applications can be written as if normal HTTP was being used). For more information, see the SPDY project page.

The Datastore, the Services and the Standard Interfaces

App Engine provides scalable services that apps can use to store persistent data, access resources over the network, and perform other tasks like manipulating image data. You have the choice between two different data storage options differentiated by their availability and consistency guarantees. Where possible, the Java interfaces to these services conform to established standard APIs to allow for porting apps to and from App Engine. Each service also provides a complete low-level interface for implementing new interface adapters, or for direct access.

Apps can use the App Engine datastore for reliable, scalable persistent storage of data. The datastore supports two standard Java interfaces: Java Data Objects (JDO) 2.3 and Java Persistence API (JPA) 1.0. These interfaces are implemented using DataNucleus Access Platform, the open source implementation of these standards.

The App Engine Memcache provides fast, transient distributed storage for caching the results of datastore queries and calculations. The Java interface implements JCache (JSR 107).

Apps use the URL Fetch service to access resources over the web, and to communicate with other hosts using the HTTP and HTTPS protocols. Java apps can simply use java.net.URLConnection and related classes from the Java standard library to access this service.

An app can use the Mail service to send email messages on behalf of the application's administrators, or on behalf of the currently signed-in user. Java apps use the JavaMail interface for sending email messages.

The Images service lets applications transform and manipulate image data in several formats, including cropping, rotating, resizing, and photo color enhancement. The service can handle CPU-intensive image processing tasks, leaving more resources available for the application server to handle web requests. (You can also use any JVM-based image processing software on the application server, provided it operates within the sandbox restrictions.)

An application can use Google Accounts for user authentication. Google Accounts handles user account creation and sign-in, and a user that already has a Google account (such as a GMail account) can use that account with your app. An app can detect when the current user is signed in, and can access the user's email address. Java applications can use security constraints in the deployment descriptor to control access via Google Accounts, and can detect whether the user is signed in and get the email address using the getUserPrincipal() method on the servlet request object. An app can use the low-level Google Accounts API to generate sign-in and sign-out URLs, and to get a user data object suitable for storage in the datastore.

Scheduled Tasks

An application can configure scheduled tasks that will call URLs of the application at specified intervals. For more on this, see Cron Jobs.

Java Tools

The App Engine Java SDK includes tools for testing your application, uploading your application files, and downloading log data. The SDK also includes a component for Apache Ant to simplify tasks common to App Engine projects. The Google Plugin for Eclipse adds features to the Eclipse IDE for App Engine development, testing and deployment, and includes the complete App Engine SDK. The Eclipse plugin also makes it easy to develop Google Web Toolkit applications and run them on App Engine.

The App Engine Java SDK also has a plugin for supporting development with Apache Maven.

The development server runs your application on your local computer for development and testing. The server simulates the App Engine datastore, services and sandbox restrictions. The development server can also generate configuration for datastore indexes based on the queries the app performs during testing.

A multipurpose tool called AppCfg handles all command-line interaction with your application running on App Engine. AppCfg can upload your application to App Engine, or just update the datastore index configuration so you can build new indexes before updating the code. It can also download the app's log data, so you can analyze your app's performance using your own tools.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License.

Last updated June 25, 2013.