Skip to content

launcher: support system java when it is a shim - #19443

Open
yaauie wants to merge 2 commits into
elastic:mainfrom
yaauie:localdev-jenv-support
Open

launcher: support system java when it is a shim#19443
yaauie wants to merge 2 commits into
elastic:mainfrom
yaauie:localdev-jenv-support

Conversation

@yaauie

@yaauie yaauie commented Aug 20, 2026

Copy link
Copy Markdown
Member

Release notes

  • [rn:skip] does not affect bundled-JDK artifacts

What does this PR do?

Help the vendored jruby.sh loader to correctly resolve a JAVA_HOME from the JAVACMD we provide it by asking java what its home is when the one on our path isn't inside of a directory structure that looks like a valid java home.

This enables our launchers to work with a "system java" that is actually a shim like the one maintained by jenv, while still trusting a resolved java executable that is inside of an approprtiately-shaped java home.

This has no affect on bundled-JDK artifacts, since the presence of a bundled JDK preempts our attempts to use a system JDK.

Why is it important/What is the impact to the user?

As a dev, I use jenv to manage my javas, and in local dev entrypoints like bin/logstash-plugin lose track of the java version declared in the project's .java-version and fall through to my system default, which is unsupported.

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
    - [ ] I have made corresponding changes to the documentation
    - [ ] I have made corresponding change to the default configuration files (and/or docker env variables)
    - [ ] I have added tests that prove my fix is effective or that my feature works

Author's Checklist

  • [ ]

How to test this PR locally

  1. ensure command -v java resolves to a jenv shim (e.g., ~/.jenv/shims/java)
  2. ensure that the global jenv resolves to an unsupported java (like my OS's default 1.8)
  3. invoke bin/logstash-plugin list --verbose
  4. observe that it actually works with this patch, or fails with Detected Java version: 1.8 without this patch

Help the vendored jruby.sh loader to correctly resolve a JAVA_HOME from
the JAVACMD we provide it by asking java what its home is when the one on
our path isn't inside of a java home.

This enables our launchers to work with a "system java" that is actually a
shim like the one maintained by jenv, while still trusting a resolved java
executable that is inside of an approprtiately-shaped java home.
@github-actions

Copy link
Copy Markdown
Contributor

🤖 GitHub comments

Just comment with:

  • run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)
  • run exhaustive tests : Run the exhaustive tests Buildkite pipeline.

@mergify

mergify Bot commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

This pull request does not have a backport label. Could you fix it @yaauie? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

  • backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit.
  • If no backport is necessary, please add the backport-skip label

@infra-vault-gh-plugin-prod

Copy link
Copy Markdown

💛 Build succeeded, but was flaky

Failed CI Steps

History

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant