Unterschiede zwischen Java 8 und Java 11/17

Durch die Migration zu den Java 11/17-Laufzeiten (Vorschau) können Sie die neuesten Sprachfunktionen verwenden und Anwendungen erstellen, die portabler sind und idiomatischen Code nutzen.

Informationen zu Migrationsoptionen

Zur Reduzierung des Aufwands und der Komplexität der Laufzeitmigration können Sie mit der App Engine-Standardumgebung auf viele gebündelte Legacy-Dienste und -APIs in der Java 11/17-Laufzeit zugreifen wie z. B. Memcache. Ihre Java 11/17-Anwendung kann die gebündelten Dienst-APIs über das App Engine API-JAR aufrufen und auf die meisten Funktionen der Java 8-Laufzeitumgebung zugreifen.

Sie haben auch die Möglichkeit, Google Cloud-Produkte zu verwenden, die vergleichbare Funktionen wie die gebündelten Legacy-Dienste bereitstellen. Diese Google Cloud-Produkte bieten idiomatische Cloud-Clientbibliotheken für Java. Für die gebündelten Dienste, die in Google Cloud nicht als separate Produkte verfügbar sind, wie Bildverarbeitung, Suche und Messaging, können Sie Drittanbieter oder andere Problemumgehungen verwenden.

Weitere Informationen zur Migration zu nicht gebündelten Diensten finden Sie unter Von gebündelten Diensten migrieren.

Je nachdem, ob Sie gebündelte Legacy-Dienste verwenden, gibt es einige Unterschiede bei der Ausführung der Laufzeitmigration:

Mit gebündelten Diensten zu Java 11/17 migrieren Zu Java 11/17 ohne gebündelte Dienste migrieren

Mit der JAR-Datei der App Engine APIs auf gebündelte Dienste zugreifen Optional können Sie empfohlene Google Cloud-Produkte oder Drittanbieterdienste verwenden.

Mit gebündelten Diensten zu Java 11/17 migrieren	Zu Java 11/17 ohne gebündelte Dienste migrieren
Mit der JAR-Datei der App Engine APIs auf gebündelte Dienste zugreifen	Optional können Sie empfohlene Google Cloud-Produkte oder Drittanbieterdienste verwenden.
Verwenden Sie `appengine-web.xml` und `web.xml` für die Anwendungskonfiguration. Abhängig von den Features der Anwendung müssen Sie möglicherweise zusätzliche YAML-Dateien konfigurieren.	Verwenden Sie `app.yaml` für die Anwendungskonfiguration. Abhängig von den Features der Anwendung müssen Sie möglicherweise zusätzliche YAML-Dateien konfigurieren.
Anwendungen werden über Jetty bereitgestellt. Verwenden Sie das WAR-Format, um Ihre Anwendung zu verpacken.	Anwendungen werden mit Ihrem eigenen Server bereitgestellt. Verwenden Sie das JAR-Format, um Ihre Anwendung zu verpacken. Weitere Informationen zum Konvertieren Ihrer vorhandenen WAR-Datei in eine ausführbare JAR-Datei finden Sie unter WAR-Datei verpacken.

Verwenden Sie appengine-web.xml und web.xml für die Anwendungskonfiguration.

Abhängig von den Features der Anwendung müssen Sie möglicherweise zusätzliche YAML-Dateien konfigurieren.

Verwenden Sie app.yaml für die Anwendungskonfiguration.

Abhängig von den Features der Anwendung müssen Sie möglicherweise zusätzliche YAML-Dateien konfigurieren.

Anwendungen werden über Jetty bereitgestellt. Verwenden Sie das WAR-Format, um Ihre Anwendung zu verpacken. Anwendungen werden mit Ihrem eigenen Server bereitgestellt. Verwenden Sie das JAR-Format, um Ihre Anwendung zu verpacken. Weitere Informationen zum Konvertieren Ihrer vorhandenen WAR-Datei in eine ausführbare JAR-Datei finden Sie unter WAR-Datei verpacken.

Übersicht über den Migrationsprozess

Im Folgenden sind einige Änderungen aufgeführt, die Sie möglicherweise an Ihrer vorhandenen App Engine Java 8-Anwendung und Ihrem Bereitstellungsprozess vornehmen müssen, um die App Engine Java 11/17-Laufzeit zu verwenden:

Google Cloud CLI herunterladen
Migration vom eigenständigen App Engine-Maven-Plug-in zum gcloud CLI-basierten Maven-Plug-in oder zum gcloud CLI-basierten Gradle-Plug-in.
Installieren Sie die App Engine API JAR, wenn Sie die gebündelten Legacy-Dienste verwenden.
Migrieren Sie Ihre XML-Dateien in die entsprechenden yaml-Dateien.

Hinweis: Wenn Sie die gebündelten App Engine-Legacy-Dienste für Java 11/17 verwenden möchten, müssen Sie eine appengine-web.xml-Datei anstelle von app.yaml haben, um Ihre Java 11/17-Anwendungen zu konfigurieren.

Hauptunterschiede zwischen den Java 8- und Java 11/17-Laufzeiten

Im Folgenden finden Sie eine Zusammenfassung der Unterschiede zwischen den Java 8- und Java 11/17-Laufzeiten in der App Engine-Standardumgebung:

	Java 8-Laufzeit	Java 11/17-Laufzeiten
Serverbereitstellung	Für Sie über Jetty bereitgestellter Server	Wenn Ihre Anwendung die gebündelten Legacy-Dienste nicht verwendet, müssen Sie selbst einen Server bereitstellen.¹
Gebündelte Legacy-Dienste	Bereitgestellt	Bereitgestellt
Fähigkeit zur Verwendung von Cloud-Clientbibliotheken für Java	Ja	Ja
Unterstützung von Sprachenerweiterungen und Systembibliotheken	Ja	Ja
Externer Netzwerkzugriff	Ja	Ja
Dateisystemzugriff	Lese- / Schreibzugriff auf `/tmp`	Lese- / Schreibzugriff auf `/tmp`
Sprachlaufzeit	Für App Engine geändert	Unveränderte Open-Source-Laufzeit
Isolationsmechanismus	gVisor-basierte Container-Sandbox	gVisor-basierte Container-Sandbox
Mit lokalem Entwicklungsserver testen	Unterstützt	Unterstützt
Logging	Verwendet einen `java.util.logging.` `ConsoleHandler`, der in `stderr` schreibt und den Stream nach jedem Eintrag leert.	Standardmäßiges Cloud Logging²

Hinweise:

Wenn Ihre Anwendung keine gebündelten Legacy-Dienste verwendet, kann die Java 11/17-Laufzeitumgebung jedes Java-Framework ausführen, solange Sie einen Webserver verpacken. Dieser ist so konfiguriert, dass er auf HTTP-Anfragen auf dem Port antwortet, der durch die Umgebungsvariable PORT (empfohlen) oder auf Port 8080 angegeben wird. Beispiel: Die Java 11/17-Laufzeiten können eine Spring Boot Uber-JAR-Datei unverändert ausführen. Weitere Beispiele finden Sie im Abschnitt Framework-Flexibilität.

Wenn Ihre Anwendung gebündelte Legacy-Dienste verwendet, stellt App Engine sie mithilfe von Jetty auf die gleiche Weise wie in der Java 8-Laufzeit bereit.
Das Logging in Java 11/17-Laufzeiten folgt dem Logging-Standard in Cloud Logging. In der Java 11/17-Laufzeit werden Anwendungslogs nicht mehr mit den Anfragelogs gebündelt, sondern in verschiedenen Einträgen getrennt. Weitere Informationen zum Lesen und Schreiben von Logs in Java 11/17-Laufzeiten finden Sie in der Logging-Anleitung.

Framework-Flexibilität

Die Java 11/17-Laufzeiten enthalten nur dann ein Web-Serving-Framework, wenn Sie die gebündelten Legacy-Dienste verwenden. Dies bedeutet, dass Sie ein anderes Framework als ein Servlet-basiertes Framework verwenden können. Wenn Sie die gebündelten Legacy-Dienste verwenden, stellen die Java 11/17-Laufzeiten das Jetty-Web-Serving-Framework bereit.

Im Google Cloud GitHub-Repository gibt es hello world-Beispiele, die gängige Java-Web-Frameworks verwenden:

XML-Dateien in YAML-Dateien migrieren

Die gcloud CLI unterstützt folgende Dateiformate nicht:

cron.xml
datastore-index.xml
dispatch.xml
queue.xml

Die folgenden Beispiele zeigen, wie Sie Ihre xml-Dateien in yaml-Dateien migrieren können.

Dateien automatisch migrieren

So migrieren Sie Ihre xml-Dateien automatisch:

Sie benötigen die Version 226.0.0 oder höher der gcloud CLI. So führen Sie ein Update auf die neueste Version aus:
```
gcloud components update
```
Geben Sie für jede Datei, die Sie migrieren möchten, einen der folgenden Unterbefehle (cron-xml-to-yaml, datastore-indexes-xml-to-yaml, dispatch-xml-to-yaml, queue-xml-to-yaml ) und den Dateinamen an:
```
gcloud beta app migrate-config queue-xml-to-yaml MY-QUEUE-XML-FILE.xml
```
Prüfen Sie manuell die konvertierte Datei, bevor Sie sie in der Produktionsumgebung bereitstellen.

Eine Beispielkonvertierung von xml zu yaml finden Sie unter den Tabs Dateien manuell migrieren.

Dateien manuell migrieren

So migrieren Sie Ihre xml-Dateien manuell in yaml-Dateien:

`cron.yaml`

Erstellen Sie eine Datei cron.yaml mit einem cron-Objekt. Dieses muss wiederum Objekte jeweils mit den Feldern enthalten, die den <cron>-Tag-Attributen in Ihrer cron.xml-Datei entsprechen, wie unten gezeigt.

Konvertierte cron.yaml-Datei:

cron:
- url: '/recache'
  schedule: 'every 2 minutes'
  description: 'Repopulate the cache every 2 minutes'
- url: '/weeklyreport'
  schedule: 'every monday 08:30'
  target: 'version-2'
  timezone: 'America/New_York'
  description: 'Mail out a weekly report'

Original cron.xml-Datei:

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
  <cron>
    <url>/recache</url>
    <description>Repopulate the cache every 2 minutes</description>
    <schedule>every 2 minutes</schedule>
  </cron>
  <cron>
    <url>/weeklyreport</url>
    <description>Mail out a weekly report</description>
    <schedule>every monday 08:30</schedule>
    <timezone>America/New_York</timezone>
    <target>version-2</target>
  </cron>
</cronentries>

Weitere Informationen finden Sie in der Referenzdokumentation zu cron.yaml.

`dispatch.yaml`

Erstellen Sie eine dispatch.yaml-Datei mit einem dispatch-Objekt. Dieses muss wiederum Objekte jeweils mit den Feldern enthalten, die den <dispatch>-Tag-Attributen in Ihrer dispatch.xml-Datei entsprechen, wie unten gezeigt.

Konvertierte dispatch.yaml-Datei:

dispatch:
- url: '*/favicon.ico'
  module: default
- url: 'simple-sample.uc.r.appspot.com/'
  module: default
- url: '*/mobile/*'
  module: mobile-frontend

Original dispatch.xml-Datei:

<?xml version="1.0" encoding="UTF-8"?>
<dispatch-entries>
  <dispatch>
      <url>*/favicon.ico</url>
      <module>default</module>
  </dispatch>
  <dispatch>
      <url>simple-sample.uc.r.appspot.com/</url>
      <module>default</module>
  </dispatch>
  <dispatch>
      <url>*/mobile/*</url>
      <module>mobile-frontend</module>
  </dispatch>
</dispatch-entries>

Weitere Informationen finden Sie in der Referenzdokumentation zu dispatch.yaml.

`index.yaml`

Erstellen Sie eine index.yaml-Datei mit einem indexes-Objekt. Dieses muss wiederum Objekte jeweils mit den Feldern enthalten, die den <datastore-index>-Tag-Attributen in Ihrer datastore-indexes.xml-Datei entsprechen, wie unten gezeigt.

Konvertierte index.yaml-Datei:

indexes:
- ancestor: false
  kind: Employee
  properties:
  - direction: asc
    name: lastName
  - direction: desc
    name: hireDate
- ancestor: false
  kind: Project
  properties:
  - direction: asc
    name: dueDate
  - direction: desc
    name: cost

Original datastore-index.xml-Datei:

<?xml version="1.0" encoding="utf-8"?>
<datastore-indexes
 autoGenerate="true">
   <datastore-index kind="Employee" ancestor="false">
       <property name="lastName" direction="asc" />
       <property name="hireDate" direction="desc" />
   </datastore-index>
   <datastore-index kind="Project" ancestor="false">
       <property name="dueDate" direction="asc" />
       <property name="cost" direction="desc" />
   </datastore-index>
</datastore-indexes>

Weitere Informationen finden Sie in der Referenzdokumentation zu index.yaml.

`queue.yaml`

Erstellen Sie eine queue.yaml-Datei mit einem queue-Objekt. Dieses muss wiederum Objekte jeweils mit den Feldern enthalten, die den <queue>-Tag-Attributen in Ihrer queue.xml-Datei entsprechen, wie unten gezeigt.

Konvertierte queue.yaml-Datei:

queue:
- name: fooqueue
  mode: push
  rate: 1/s
  retry_parameters:
    task_retry_limit: 7
    task_age_limit: 2d
- name: barqueue
  mode: push
  rate: 1/s
  retry_parameters:
    min_backoff_seconds: 10
    max_backoff_seconds: 200
    max_doublings: 0

Original queue.xml-Datei:

<queue-entries>
  <queue>
    <name>fooqueue</name>
    <rate>1/s</rate>
    <retry-parameters>
      <task-retry-limit>7</task-retry-limit>
      <task-age-limit>2d</task-age-limit>
    </retry-parameters>
  </queue>
  <queue>
    <name>barqueue</name>
    <rate>1/s</rate>
    <retry-parameters>
      <min-backoff-seconds>10</min-backoff-seconds>
      <max-backoff-seconds>200</max-backoff-seconds>
      <max-doublings>0</max-doublings>
    </retry-parameters>
  </queue>
<queue-entries>