Remarque : Java 8 n'est plus pris en charge depuis le 31 janvier 2024. Vos applications Java 8 existantes continueront à fonctionner et à recevoir du trafic. Toutefois, App Engine peut bloquer le redéploiement des applications qui utilisent des environnements d'exécution après leur date de fin de compatibilité. Nous vous recommandons de migrer vers la dernière version compatible de Java.

Migrer de l'environnement d'exécution Java 7 vers Java 8

Cette page explique comment migrer votre application App Engine existante de l'environnement d'exécution Java 7 vers l'environnement Java 8. Notez que les environnements d'exécution Java pour App Engine sont basés sur OpenJDK.

Spécifier l'environnement d'exécution Java 8 pour votre application

Pour exécuter votre application dans l'environnement d'exécution Java 8 :

Ajoutez <runtime>java8</runtime> à votre fichier appengine-web.xml.

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

Redéployez votre application.

Migrer depuis des services non compatibles

Certains services obsolètes, disponibles dans l'environnement d'exécution Java 7, ne sont pas compatibles avec l'environnement Java 8. Google vous recommande de migrer votre application vers les alternatives recommandées et, avant de migrer vers l'environnement Java 8, de la tester dans l'environnement Java 7 avec ces modifications.

Les services obsolètes suivants ne sont pas disponibles dans l'environnement d'exécution Java 8 :

Service obsolète	Alternative recommandée
Cloud Endpoints v1	Migrez vers la version 2, le produit a été renommé Cloud Endpoints Frameworks. Notez que cela vous obligera peut-être à modifier vos applications Web, Android ou iOS.
AppStats (appengine-api-labs jar)	Migrez vers Cloud Trace. Le SDK génère une erreur pour les applications utilisant la classe `com.google.appengine.tools.AppstatsFilter` dans l'environnement d'exécution Java 8. Veillez à bien supprimer toutes les références à `AppstatsFilter` dans votre fichier `web.xml`.

Les classes réempaquetées nécessitent de nouveaux chemins d'importation avec Java 8. Par exemple, si votre application utilise com.google.appengine.repackaged.com.google.common.base.Optional, vous devez importer com.google.appengine.repackaged.com.google.common.base.$Optional, en préfixant le nom de la classe par $.

Migrer des applications gratuites utilisant java.net.HttpURLConnection

Si la facturation n'est pas activée dans votre application, mais que celle-ci effectue des requêtes HTTP(S) à l'aide de la classe java.net.HttpURLConnection ou d'une bibliothèque cliente Google qui utilise cette classe, cela provoque des erreurs d'exécution. Pour les éviter, définissez <url-stream-handler> sur urlfetch dans le fichier appengine-web.xml de votre application :

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <url-stream-handler>urlfetch</url-stream-handler>
  <!-- ... -->
</appengine-web-app>

Une autre solution, au lieu de spécifier urlfetch, consiste à activer la facturation pour votre application et à utiliser le paramètre native par défaut. Les coûts liés à l'exécution de votre application ne devraient subir aucune augmentation par rapport à l'environnement Java 7. Notez que si votre application exploite l'en-tête HTTP X-Appengine-Inbound-Appid (utilisé pour la communication entre modules), vous devez utiliser urlfetch.

Modifier l'encodage de fichier par défaut

App Engine a modifié l'encodage de fichier par défaut, passant de l'encodage US-ASCII dans Java 7 à UTF-8 dans Java 8. Pour rétablir l'encodage par défaut à US-ASCII dans Java 8, ajoutez les lignes suivantes à votre fichier appengine-web.xml :

 <system-properties>
   <property name="appengine.file.encoding" value="US-ASCII"/>
 </system-properties>

Des erreurs peuvent survenir si certains caractères ne figurent pas dans le jeu de caractères ASCII et que votre application repose sur certains présupposés, par exemple someString.getBytes().length == someString.length(). Avec l'encodage US-ASCII, cette égalité est vraie, car les caractères non-ASCII sont mappés en "?". Cependant, ce n'est pas nécessairement vrai avec l'encodage UTF-8.

Par exemple, si vous imprimez les octets hexadécimaux résultant de l'instruction Éamonn.getBytes(), en UTF-8, vous obtiendrez : c3 89 61 6d 6f 6e 6e (Éamonn), tandis qu'en US-ASCII vous obtiendrez : 3f 61 6d 6f 6e 6e (?amonn) en raison de la différence d'encodage du caractère É.

Tirer pleinement parti des fonctionnalités de l'environnement d'exécution Java 8

Vous trouverez ci-dessous une liste partielle des avantages que présente la migration vers l'environnement d'exécution Java 8 :

Jetty 9 est compatible avec les applications Web Servlet 2.5 et 3.1, y compris les annotations de servlets.
Toutes les classes standards de Java sont maintenant disponibles et il n'y a pas de liste d'autorisation de classes.
Le système de fichiers /tmp est accessible en écriture, et profite de l'installation sur les disques RAM de l'application.
Les E/S réseau peuvent maintenant être réalisées sur n'importe quel thread Java. Les appels à l'API App Engine nécessitent toujours d'être sur un thread de requête ou sur un thread créé par l'API Thread Manager.
Le langage Java 8 est désormais compatible dans son intégralité, y compris les lambdas et les API Stream et Date/Time.