Skip to content

Launcher can't find JAVA_HOME running with Linux alternatives #31

Open
Open
Launcher can't find JAVA_HOME running with Linux alternatives#31

Description

@headius
headius
opened on Mar 20, 2020

Most of the issues reported under jruby/jruby#6049 appear to be due to the fact that we can't detect that the JDK being used supports modules.

Normally if you have JAVA_HOME set to the location of your JDK, we will look for JAVA_HOME/jmods to determine that the JDK supports modules. In some scenarios, only java will be in path. The logic at present assumes that java is under JAVA_HOME/bin, and infers JAVA_HOME From that path. Unfortunately on most Linux distributions, java is installed as a link in /usr/bin, so we can't determine from that path where JAVA_HOME is actually located.

I believe we need a more robust mechanism to determine that the target JDK supports modules.

The workaround for now is to set JAVA_HOME. On most Linux distributions, there will be commands you can run to get the location of the default JDK installation. The JDKs are also usually installed under /usr/lib/jvm; paths there are suitable for JAVA_HOME (just make sure they match the default version of Java run by /usr/bin/java).

Activity

  1. deivid-rodriguez commented on Mar 21, 2020

    @deivid-rodriguez
    deivid-rodriguez
    on Mar 21, 2020
    Contributor

    Thank you @headius, I'll play around to figure out the proper value of JAVA_HOME to get this to work.

    It seems to me from what you wrote that it would be enough to resolve the real location of java if it's a symlink before all the current logic to figure out the JAVA_HOME?

  2. enebo commented on Mar 21, 2020

    @enebo
    enebo
    on Mar 21, 2020
    Member

    @deivid-rodriguez I am doing a spike of writing this launcher in rust. What is described with alternatives is a single function (fs::canonicalize(path)) and if we do continue with the existing launcher it will likely need to be readlink in a loop since /usr/bin/java -> /etc/alternatives/java -> /the/actual/location.

  3. deivid-rodriguez commented on Mar 21, 2020

    @deivid-rodriguez
    deivid-rodriguez
    on Mar 21, 2020
    Contributor

    @enebo Ruby's File.realpath seems to handle that just fine:

    $ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 ago 21  2019 /usr/bin/java -> /etc/alternatives/java

$ jruby -e 'puts File.realpath("/usr/bin/java")'
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.headius.backport9.modules.Modules to method sun.nio.ch.NativeThread.signal(long)
WARNING: Please consider reporting this to the maintainers of com.headius.backport9.modules.Modules
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
/usr/lib/jvm/java-11-openjdk-amd64/bin/java

    And the workaround works, by the way! 🎉

    $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 jruby -e "puts 1"
1

  4. headius commented on Mar 23, 2020

    @headius
    headius
    on Mar 23, 2020
    MemberAuthor

    Another way to get JAVA_HOME:

    $ jruby -e 'puts ENV_JAVA["java.home"]'
/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home

    We are probably not going to go further with this in the existing launcher codebase since the new Rust-based launcher has been coming along well. I would recommend anyone using JRuby have a JAVA_HOME set until we have the newer, smarter launcher to handle that for you.

  5. nfrankel commented on Nov 27, 2020

    @nfrankel
    nfrankel
    on Nov 27, 2020

    I'm using the jruby:9.2-jre11 Docker image.

    > echo $JAVA_HOME
/usr/local/openjdk-11

> which java
/usr/local/openjdk-11/bin/java

> JAVA_HOME=/usr/local/openjdk-11/ jruby -e "puts 1"
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.headius.backport9.modules.Modules to method sun.nio.ch.NativeThread.signal(long)
WARNING: Please consider reporting this to the maintainers of com.headius.backport9.modules.Modules
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
1

    However, when I execute find / -name jmod, it yields no result.

  6. headius commented on Dec 2, 2020

    @headius
    headius
    on Dec 2, 2020
    MemberAuthor

    @nfrankel What version of JRuby is in that docker image? We were supposed to take over maintenance but have not had time to do so. It may be out of date.

  7. nfrankel commented on Dec 2, 2020

    @nfrankel
    nfrankel
    on Dec 2, 2020
    ruby --version
    jruby 9.2.11.1 (2.5.7) 2020-03-25 b1f55b1a40 OpenJDK 64-Bit Server VM 11.0.7+10 on 11.0.7+10 +jit [linux-x86_64]

  8. headius commented on Dec 2, 2020

    @headius
    headius
    on Dec 2, 2020
    MemberAuthor

    jruby 9.2.11.1

    😬 Yikes, ok, we need to get those images taken over and updated to latest JRuby.

    Workaround for now would be to manually force a newer JRuby by downloading or installing it in the container.

  9. nfrankel commented on Dec 2, 2020

    @nfrankel
    nfrankel
    on Dec 2, 2020

    No worries, I can live with a warning until the new image is provided. Thanks for the feedback!

  10. deivid-rodriguez commented on Dec 3, 2020

    @deivid-rodriguez
    deivid-rodriguez
    on Dec 3, 2020
    Contributor

    The docker images seem up to date though: https://hub.docker.com/_/jruby/. I think you need to docker pull to update your base image.

  11. nfrankel commented on Dec 3, 2020

    @nfrankel
    nfrankel
    on Dec 3, 2020

    Thanks for the hint @deivid-rodriguez. The image was from 5 months ago, there's indeed a new one... and a new warning message.

    WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.ext.openssl.SecurityHelper (file:/opt/jruby/lib/ruby/stdlib/jopenssl.jar) to field java.security.MessageDigest.provider
WARNING: Please consider reporting this to the maintainers of org.jruby.ext.openssl.SecurityHelper
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

    On a meta level, this raises the question as to why the tag may reference different image hashes over time. Since it's the second time I encounter this behavior, I'm less surprised, but I do think this is not a good idea.

  12. deivid-rodriguez commented on Dec 3, 2020

    @deivid-rodriguez
    deivid-rodriguez
    on Dec 3, 2020
    Contributor

    You have different options for specifying your base docker image, which go from yours, jruby:9.2-jre11, meaning "give me the latest patch level version of the 9.2 series", to more constraining such as jruby:9.2.13.0-jre11, meaning give me exactly the base image tagged as 9.2.13.0, but potentially including changes still being tagged as 9.2.13.0 (for example, a bug fix in the Dockerfile) to the fully deterministic jruby:9.2.13.0@sha256:8b217bb79ecaec62b2ea86f7389348cca44a9a6446c50b1da13fd2f40df91687.

    Regarding the warning, you can also try upgrading the jruby-openssl gem to 0.10.5.

  13. nfrankel commented on Dec 3, 2020

    @nfrankel
    nfrankel
    on Dec 3, 2020

    @deivid-rodriguez Makes sense, thanks for the explanation

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions