Why does ES need Java 14 to build?

Elastic Stack Elasticsearch
1

Hi,

I want to create a custom processing plugin for ES and I ran into the problem that apparently building anything for ES 7.7.0 requires Java 14 ( see https://github.com/elastic/elasticsearch/pull/54696 ).

Yet the https://www.elastic.co/support/matrix#matrix_jvm states runtime 1.8 is still supported and also it states
Java 9, Java 10, Java 12, and Java 13 are short term releases. We advise against using them unless you're prepared to handle the fast release cadence this imposes.

What is the point of requiring a javac several versions newer than what the output binaries (runtime) should support?

2

Elasticsearch itself is required to run on a variety of different JDKs but there's a good deal of supporting infrastructure in the codebase (tests, the build system itself) that doesn't have that constraint and so can make use of features that are only available in newer JDKs. The real build process only ever uses a single Java version so it'd be a bit pointless to put effort into making sure that it works with all the other versions too.

1 Like
3

Yes, I can understand only using a single JDK for development is great to simplify that.
Then supporting any runtime from 1.8 and up (or as with 8.0.0 supporting JRE 11 and up) is also fully understandable from a "newer" build setup.
I'm just very curious what feature requires the build environment to be in the latest "intermediate" Java (right now 14). What makes it that it really NEEDS Java 14?
The reason is that because of this hardcoded check I now MUST run the build environment of my ES plugin also in Java 14 because the build-utils fail if I don't.

4

I suspect that today the build doesn't technically need version 14 for anything (other than to pass those checks) but I'm also pretty sure it needs something newer than 1.8. You can probably work out how to build things with an older version. The reason for requiring version 14 by default is part of a more general development philosophy: we try only to be lenient having made a conscious decision that the benefits of lenience outweigh its costs. There are nontrivial costs to lenience in the build environment (it adds a whole extra dimension to the testing and debugging space) and the benefits are small (it's really easy to install JDK14 for the relatively few developers who wish to build Elasticsearch) so strictness is the appropriate choice.

5

I suppose your question might be more about why we use a non-LTS release (JDK14) rather than the latest LTS release (JDK11) for the build environment. I don't think there's a good reason to stick only to LTS releases, builds are effectively one-shot executions so there's no need for long-term support. Also the gaps between LTS releases are enormous, and big-jump upgrades are always a lot more painful than smaller ones, so the release cadence of non-LTS releases is preferable.

6

Yes, for those who want to build ElasticSearch I fully agree with this.
However the way this check has been constructed it now also applies to anyone who wants (externally) to build a plugin for ES using for example https://github.com/spinscale/cookiecutter-elasticsearch-ingest-processor and use the build-utils as the testing environment.
That is where my pain comes from.
I do not want to force Java 14 to build my project.
I can agree to java 11, but java 14 is too new for my taste.

7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.