No-jdk distribution of opensearch?

elasticsearch so far came in two flavours (well, many more actually): one with the JDK bundled and one without the JDK bundled.

the latter issues a warning on startup that this is deprecated and will not be supported in the future:

warning: no-jdk distributions that do not bundle a JDK are deprecated and will be removed in a future release

what are the plans of opensearch here?

  • directly abandon the no-jdk distribution
  • keep the no-jdk distribution but flag it as deprecated and kick it out with a future major release
  • keep the no-jdk distribution fully supported

what is the update strategy for the bundled JDK? how fast will you update all still supported versions of opensearch with an updated JDK if one comes out (esp. if that contains security fixes)?
and which JDK do you plan to bundle, anyway? (with all the licensing implications, etc.)

having the no-jdk distribution has the advantage that we can roll our own docker image with our preferred base image (which is trusted, signed & security-reviewed and contains the latest JDK in the flavour we prefer). this allows us to have a very homogenous landscape in terms of JVMs running in our application stack (makes tracking bugs & security relevant things easier) and - typical big corporation - makes getting approvals from security & co. easier (i don’t have to onboard yet another JDK / JDK vendor).

That’s a good question actually @ralph.

That message is still present in OpenSearch and seems to be just ported across during the forking. I’ve personally not heard any talk of deprecating no-jdk.

Your reasoning seems pretty sound to me. I’d like to hear what others say but barring any major dissenters, it might be a basis for a more formal proposal.


Yeah, I’d love to hear preferences and ideas about how to mitigate the tradeoffs for a feature like this. Obviously, it’s easy to set a different JAVA_HOME to replace/override the bundled JDK with one of your preference, even in the bundled-jdk distribution - but that still does involved downloading bytes you aren’t going to use.

For users of a no-JDK version, what would you expect as far as how thoroughly OpenSearch is tested/supported with JDKs other than the one it’s normally shipped with? Would it be preferable to have the ability to choose among distributions that are built / shipped / tested with specific JDKs, if that made it easier for those JDKs to be supported?

1 Like

if i saw it correctly then elasticsearch is bundling AdoptOpenJDK. what are the plans for opensearch? will you continue with this or will you e.g. move to Amazon Corretto (because opensearch is currently mainly driven by AWS, so you might have some interest in using your own products)?
i’m actually fine with AdoptOpenJDK and think that it makes sense to test against this, since it’s - according to wikipedia - an unmodified build from upstream (unlike most others). so if it works with that it should work with others.

then the question remains for how updates to the JDK will be handled. because, even if it’s an “accepted” JDK not having the updates under control is a bit of an issue.

downloading opensearch with a bundled JDK but then using your own JDK instead feels wrong:

  • you waste valuable storage space, esp. in docker images
  • security & license scanning tools will still always pick up the bundled JDK (these tools are not intelligent enough to understand that you’re not using it even though it’s in your container)
  • if you instead delete the bundled JDK every time this is just an unnecessary additional step and makes things more complex than they need to be
1 Like

Yeah @ralph, it makes total sense that if you’re planning to use a different JDK anyway, it would be great to have an ability to not even download the default one.

Any discussion of changing the default JDK would happen here and/or with an RFC. The long term support offered with Amazon Corretto is appealing, as it would provide a straightforward answer to your question about how to handle JDK updates: the upstream vendor would have a stated support commitment. But there are a ton of variables to consider.

My question around the ‘no-bundled-jdk’ option is, would you as a user expect “no JDK” to effectively mean “all JDKs” - i.e. that releases are tested and supported equally well for any JDK you choose to use? That could get complex. Or would there be a different expectation? How do you think about this?

this just answers the part of the JDK vendor. it does not answer how fast opensearch will be able to publish an update to the distribution.

we’re currently also using AdoptOpenJDK, so the main reason for me to use the no-jdk distribution would be that i can use our “standard” in-house java base image which is kept up-to-date and is guaranteed to be set up in a way our infrastructure & security people are happy with and we have an easy way to track if we need to update something. if it comes as a black box with opensearch we might not notice if it’s outdated (or rather: we’ll notice it, but via our scanning tools and worst case we’ll have to wait for a new opensearch release to update the JDK).

as stated before i think that if you test against an unmodified JDK (e.g. AdoptOpenJDK) then it should be fine. anyone using a modified JDK has to ensure compatibility on their own.

i just noticed that the “minimal” distribution (Opensearch 1.0.0 Min Linux X64 · OpenSearch) still ships with a JDK.
is this intentional? i was really hoping that the minimal distribution would be without a JDK.
or could we get a “minimal-no-jdk” (and maybe also a “normal” “no-jdk”) distribution?

should i raise a ticket (didn’t find an open one for this) for this or are there specific reasons why you absolutely wouldn’t want to do this?

1 Like

Definitely please open an issue in the build repo. That would be a big help!

We’re working to add more distribution options that users are asking for as fast as we can. There’s a list, and let’s just get this onto the list. We’re also working in parallel on an open build infrastructure that would let anybody contribute toward a new distribution type they care about, and more testing automation so that it’s easy to thoroughly test all these distributions.


thanks, that’s good news! i’ve created the ticket:

1 Like

Thank you for opening the issue, @ralph. We’ll track this there.

1 Like