Suppress illegal reflective access in shared cache

[jasontedor]

This commit temporarily supressess an illegal reflective access warning by opening the java.io module to all unnamed modules. This is needed when using the searchable snapshots shared cache due to some reflective access that occurs there. This is temporary while we explore alternatives.

Relates #70285

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[elasticmachine]

Pinging @elastic/es-distributed (Team:Distributed)

[jasontedor]

This is to suppress these lines that get dumped to stderr:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.elasticsearch.xpack.searchablesnapshots.preallocate.Preallocate$FileDescriptorFieldAction (file:/Users/jason/src/elastic/elasticsearch/build/distribution/local/elasticsearch-8.0.0-SNAPSHOT/modules/searchable-snapshots/preallocate-8.0.0-SNAPSHOT.jar) to field java.io.FileDescriptor.fd
WARNING: Please consider reporting this to the maintainers of org.elasticsearch.xpack.searchablesnapshots.preallocate.Preallocate$FileDescriptorFieldAction
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

It is a bad user experience to encounter this output.

Yes, this solution is a hammer to suppress them, but there aren't any obvious alternatives given that we are running without modules, and therefore the only way we can grant the necessary opens here are to all unnamed modules. If we were running with modules, we could open this only to the necessary module, preferably by placing the opens declaration in the JAR manifest itself.

[jasontedor]

And we will encounter a lot of noise from this line:

WARNING: Please consider reporting this to the maintainers of org.elasticsearch.xpack.searchablesnapshots.preallocate.Preallocate$FileDescriptorFieldAction

[rjernst]

What do you think about putting it in SystemJvmOptions since it is an implementation detail of the server rather than something the user should even need to think about?

[jasontedor]

@rjernst SystemJvmOptions doesn't allow us to switch on JVM version, which we need to be able to do here so that in 7.x on Java 8 we don't emit this JVM option. We can talk about adding that capability or not, so far we haven't needed it in SystemJvmOptions, but I don't think that should block this change. Additionally, we now tell users not to edit the root jvm.options.

[jasontedor]

Actually @rjernst in #54853 I already used versioning logic in SystemJvmOptions 🤦‍♀️:

elasticsearch/distribution/tools/launchers/src/main/java/org/elasticsearch/tools/launchers/SystemJvmOptions.java

Lines 63 to 69 in 79689fd

	private static String maybeShowCodeDetailsInExceptionMessages() {
	if (JavaVersion.majorVersion(JavaVersion.CURRENT) >= 14) {
	return "-XX:+ShowCodeDetailsInExceptionMessages";
	} else {
	return "";
	}
	}

I've pushed dd271d1 and when backporting to 7.12 and 7.x will do the same here.

[rjernst]

LGTM