Enable testing against JDK 13 EA builds (#40829)

This commit adds JDK 13 to the CI rotation for testing. For now, we will
be testing against JDK 13 EA builds.

Author: jasontedor

.ci/java-versions.properties

@@ -8,3 +8,4 @@ ES_BUILD_JAVA=openjdk12
 ES_RUNTIME_JAVA=java11
 GRADLE_TASK=build
 
+

.ci/matrix-build-javas.yml

@@ -7,3 +7,4 @@
 
 ES_BUILD_JAVA:
   - openjdk12
+  - openjdk13

.ci/matrix-runtime-javas.yml

@@ -9,6 +9,7 @@ ES_RUNTIME_JAVA:
   - java11
   - java12
   - openjdk12
+  - openjdk13
   - zulu11
   - zulu12
   - corretto11

server/src/main/java/org/elasticsearch/bootstrap/Security.java

@@ -61,7 +61,7 @@
 /**
  * Initializes SecurityManager with necessary permissions.
  * <br>
- * <h1>Initialization</h1>
+ * <h2>Initialization</h2>
  * The JVM is not initially started with security manager enabled,
  * instead we turn it on early in the startup process. This is a tradeoff
  * between security and ease of use:
@@ -72,7 +72,7 @@
  *       otherwise be permitted.</li>
  * </ul>
  * <br>
- * <h1>Permissions</h1>
+ * <h2>Permissions</h2>
  * Permissions use a policy file packaged as a resource, this file is
  * also used in tests. File permissions are generated dynamically and
  * combined with this policy file.
@@ -92,7 +92,7 @@
  * cleanups to the scripting apis). But still it can provide some defense for users
  * that enable dynamic scripting without being fully aware of the consequences.
  * <br>
- * <h1>Debugging Security</h1>
+ * <h2>Debugging Security</h2>
  * A good place to start when there is a problem is to turn on security debugging:
  * <pre>
  * ES_JAVA_OPTS="-Djava.security.debug=access,failure" bin/elasticsearch

server/src/main/java/org/elasticsearch/common/inject/Binder.java

@@ -31,7 +31,7 @@
  * used to create an {@link Injector}. Guice provides this object to your
  * application's {@link Module} implementors so they may each contribute
  * their own bindings and other registrations.
- * <h3>The Guice Binding EDSL</h3>
+ * <h2>The Guice Binding EDSL</h2>
  * <p>
  * Guice uses an <i>embedded domain-specific language</i>, or EDSL, to help you
  * create bindings simply and readably.  This approach is great for overall

server/src/main/java/org/elasticsearch/common/inject/assistedinject/FactoryProvider.java

@@ -39,7 +39,7 @@
 /**
  * Provides a factory that combines the caller's arguments with injector-supplied values to
  * construct objects.
- * <h3>Defining a factory</h3>
+ * <h2>Defining a factory</h2>
  * Create an interface whose methods return the constructed type, or any of its supertypes. The
  * method's parameters are the arguments required to build the constructed type.
  * <pre>public interface PaymentFactory {

server/src/main/java/org/elasticsearch/common/lucene/search/XMoreLikeThis.java

@@ -97,7 +97,7 @@
  * above.  The frequency and length thresholds could be parameters, etc.
  * Doug
  * </pre>
- * <h3>Initial Usage</h3>
+ * <h2>Initial Usage</h2>
  * <p>
  * This class has lots of options to try to make it efficient and flexible.
  * The simplest possible usage is as follows. The bold

server/src/main/java/org/elasticsearch/repositories/blobstore/package-info.java

@@ -20,7 +20,7 @@
 /**
  * <p>This package exposes the blobstore repository used by Elasticsearch Snapshots.</p>
  *
- * <h1>Preliminaries</h1>
+ * <h2>Preliminaries</h2>
  *
  * <p>The {@link org.elasticsearch.repositories.blobstore.BlobStoreRepository} forms the basis of implementations of
  * {@link org.elasticsearch.repositories.Repository} on top of a blob store. A blobstore can be used as the basis for an implementation
@@ -84,7 +84,7 @@
  * }
  * </pre>
  *
- * <h1>Getting the Repository's RepositoryData</h1>
+ * <h2>Getting the Repository's RepositoryData</h2>
  *
  * <p>Loading the {@link org.elasticsearch.repositories.RepositoryData} that holds the list of all snapshots as well as the mapping of
  * indices' names to their repository {@link org.elasticsearch.repositories.IndexId} is done by invoking
@@ -114,11 +114,11 @@
  * </ol>
  * </li>
  * </ol>
- * <h1>Creating a Snapshot</h1>
+ * <h2>Creating a Snapshot</h2>
  *
  * <p>Creating a snapshot in the repository happens in the three steps described in detail below.</p>
  *
- * <h2>Initializing a Snapshot in the Repository</h2>
+ * <h3>Initializing a Snapshot in the Repository</h3>
  *
  * <p>Creating a snapshot in the repository starts with a call to {@link org.elasticsearch.repositories.Repository#initializeSnapshot} which
  * the blob store repository implements via the following actions:</p>
@@ -130,7 +130,7 @@
  * </ol>
  * TODO: This behavior is problematic, adjust these docs once https://github.com/elastic/elasticsearch/issues/41581 is fixed
  *
- * <h2>Writing Shard Data (Segments)</h2>
+ * <h3>Writing Shard Data (Segments)</h3>
  *
  * <p>Once all the metadata has been written by the snapshot initialization, the snapshot process moves on to writing the actual shard data
  * to the repository by invoking {@link org.elasticsearch.repositories.Repository#snapshotShard} on the data-nodes that hold the primaries
@@ -158,7 +158,7 @@
  * {@code BlobStoreIndexShardSnapshots} blob is written to the shard's path with name {@code index-${N+1}}.</li>
  * </ol>
  *
- * <h2>Finalizing the Snapshot</h2>
+ * <h3>Finalizing the Snapshot</h3>
  *
  * <p>After all primaries have finished writing the necessary segment files to the blob store in the previous step, the master node moves on
  * to finalizing the snapshot by invoking {@link org.elasticsearch.repositories.Repository#finalizeSnapshot}. This method executes the
@@ -173,7 +173,7 @@
  * <li>Write the updated {@code /index.latest} blob containing the new repository generation {@code N + 1}.</li>
  * </ol>
  *
- * <h1>Deleting a Snapshot</h1>
+ * <h2>Deleting a Snapshot</h2>
  *
  * <p>Deleting a snapshot is an operation that is exclusively executed on the master node that runs through the following sequence of
  * action when {@link org.elasticsearch.repositories.blobstore.BlobStoreRepository#deleteSnapshot} is invoked:</p>

server/src/main/java/org/elasticsearch/snapshots/package-info.java

@@ -20,7 +20,7 @@
 /**
  * <p>This package exposes the Elasticsearch Snapshot functionality.</p>
  *
- * <h1>Preliminaries</h1>
+ * <h2>Preliminaries</h2>
  *
  * <p>There are two communication channels between all nodes and master in the snapshot functionality:</p>
  * <ul>
@@ -32,7 +32,7 @@
  * snapshot's entry in the cluster state accordingly.</li>
  * </ul>
  *
- * <h1>Snapshot Creation</h1>
+ * <h2>Snapshot Creation</h2>
  * <p>Snapshots are created by the following sequence of events:</p>
  * <ol>
  * <li>An invocation of {@link org.elasticsearch.snapshots.SnapshotsService#createSnapshot} enqueues a cluster state update to create
@@ -68,7 +68,7 @@
  * </li>
  * </ol>
  *
- * <h1>Deleting a Snapshot</h1>
+ * <h2>Deleting a Snapshot</h2>
  *
  * <p>Deleting a snapshot can take the form of either simply deleting it from the repository or (if it has not completed yet) aborting it
  * and subsequently deleting it from the repository.</p>

server/src/main/resources/org/elasticsearch/bootstrap/security.policy

@@ -55,6 +55,8 @@ grant codeBase "${codebase.elasticsearch-plugin-classloader}" {
 //// Everything else:
 
 grant {
+  // needed by vendored Guice
+  permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.vm.annotation";
 
   // checked by scripting engines, and before hacks and other issues in
   // third party code, to safeguard these against unprivileged code like scripts.

x-pack/plugin/sql/src/main/java/org/elasticsearch/xpack/sql/package-info.java

@@ -13,14 +13,14 @@
  * if possible, to one (at the moment) query DSL. Of course, this means
  * not all SQL queries are supported.<br>
  *
- * <h3>Premise</h3>
+ * <h2>Premise</h2>
  * Since Elasticsearch is not a database nor does it supports arbitrary
  * {@code JOIN}s (a cornerstone of SQL), SQL module is built from the
  * ground-up with Elasticsearch in mind first and SQL second. In fact,
  * even the grammar introduces Elasticsearch specific components that
  * have no concept in ANSI SQL.
  *
- * <h3>Architecture</h3>
+ * <h2>Architecture</h2>
  * SQL module is roughly based on the Volcano project (by Graefe
  * {@code &} co)
  * <a href="http://ieeexplore.ieee.org/document/344061">[1]</a>
@@ -53,7 +53,7 @@
  * (to different degrees) by the majority of SQL engines out there such
  * as Apache Calcite, Apache Impala, Apache Spark and Facebook Presto.
  *
- * <h3>Concepts</h3>
+ * <h2>Concepts</h2>
  *
  * The building operation of the SQL engine is defined by an action,
  * namely a rule (defined in {@link org.elasticsearch.xpack.sql.rule rule}
@@ -112,8 +112,8 @@
  *  <li>The Elasticsearch query gets executed</li>
  * </ol>
  *
- * <h4>Digression - Visitors, pattern matching, {@code instanceof} and
- * Java 10/11/12</h4>
+ * <h3>Digression - Visitors, pattern matching, {@code instanceof} and
+ * Java 10/11/12</h3>
  *
  * To implement the above concepts, several choices have been made in the
  * engine (which are not common in the rest of the XPack code base). In
@@ -146,7 +146,7 @@
  * {@link org.elasticsearch.xpack.sql.tree.Node#transformDown(java.util.function.Function, Class)
  * pre-order transformation}).
  *
- * <h3>Components</h3>
+ * <h2>Components</h2>
  *
  * The SQL engine is made up of the following components:
  * <dl>