The JAVA situation
I installed the java-basic bundle, yet all my Java-based applications complain that they cannot find any Java installed on my system. What am I doing wrong??
Does installing this bundle requires further (so far undocumented) steps in order to make Java work on one's system? Is this bundle not self-contained?
Interestingly, whereis java returns java: /usr/bin/java, which does not seem to be a symlink. Furthermore, java -version also complains that the java command cannot be found, as there's no JAVA_HOME variable set. Doing some further digging reveals a Java installation ... of sorts in /usr/lib/jvm/java-1.19.0.
Anyone care to disentangle this mystery? What do we have to do to get an honest-to-goodness Java installation on our CL systems?
Probably installing the java-basic bundle should export JAVA_HOME env variable.
Considering that CL is stateless, we can't add files to the user dir, but I see that default configs go to /usr/share/defaults/etc/. Perhaps something can be appended here?
Either that, or a message in swupd that tells us to export the env variable?
Probably installing the
java-basicbundle should exportJAVA_HOMEenv variable.
And, more importantly, what value should the JAVA_HOME env variable have? Where is Java installed after all? Should it be /usr/bin/java, or /usr/lib/jvm/java-1.19.0/bin/java?
JAVA_HOME doesn't lead directly to the Java binary, so it's /usr/lib/jvm/java-1.19.0 as per your previous post (which is what I use in my config)
JAVA_HOMEdoesn't lead directly to the Java binary, so it's/usr/lib/jvm/java-1.19.0as per your previous post (which is what I use in my config)
Thanks. Nevertheless, what's with this /usr/bin/java binary? Who put it there? Does the java-basic bundle dump that in there, or is that file the result of some rogue installer? (Note that in the same /usr/bin/ directory there's a whole host of java-related symlinks such as javac and the like that point to the /usr/bin/java binary, so it doesn't look to be some accident.)
/usr/bin/java is the executable (EDIT: I went down a rabbit hole https://github.com/clearlinux-pkgs/usrbinjava/blob/main/usrbinjava.spec)
the folder /usr/bin is available in the PATH so apps can use it globally
you can use it like so
i@clr~ $ java --version
openjdk 19.0.2-internal 2023-01-17
OpenJDK Runtime Environment (build 19.0.2-internal-adhoc.mockbuild.corretto-19-19.0.2.7.1)
OpenJDK 64-Bit Server VM (build 19.0.2-internal-adhoc.mockbuild.buildavx2, mixed mode)
Some apps need more than just the java binary so they want the entire JDK through the JAVA_HOME env variable. I use it with gradle for building android apps, (and for the occasional .jar file)
extra info: in windows, you dont get a java.exe, however you do get a javac.exe. I believe thats the same behaviour you're seeing here. where /usr/bin/java points to the javac binary
I believe thats the same behaviour you're seeing here. where
/usr/bin/javapoints to thejavacbinary
Actually here it's the other way around: it's javac that points to /usr/bin/java.
Anyway, thanks for investigating things. Let me attempt to draw the line on the "no multiple Javas" scenario:
- installing the
java-basicbundle should be followed by: - the adding of the following lines to the
.bashrcfile:
export JAVA_HOME=/usr/lib/jvm/java-1.19.0
export PATH=$JAVA_HOME/bin:$PATH
Is that it? Is that all?
exporting the JAVA_HOME/bin path on the PATH is something I never had to do. Apps pick up java pretty well with just /usr/bin/java and for the rest, manipulating JAVA_HOME was enough. Such as when I was building Lineage from source and it complained when it had detected my Java 19 install (Java 11 still gets updates, who knew)
In short, export JAVA_HOME=/usr/lib/jvm/java-1.19.0 is all that is needed.
In CL, I'm hoping this can be provided, with the option of being able to override it later in the /etc/ folder or something like the other config stuff
we can make this work thanks for confirming the settings that work
I'm supposed to be on vacation but William or Brett can likely just add this to our filesystem package (profile.x86_64 file)
On Sun, Dec 1, 2024, 07:41 K1ngfish3r @.***> wrote:
exporting the JAVA_HOME/bin path on the PATH is something I never had to do. Apps pick up java pretty well with just /usr/bin/java and for the rest, manipulating JAVA_HOME was enough. Such as when I was building Lineage from source and it complained when it had detected my Java 19 install (Java 11 still gets updates, who knew)
In short, export JAVA_HOME=/usr/lib/jvm/java-1.19.0 is all that is needed. In CL, I'm hoping this can be provided, with the option of being able to override it later in the /etc/ folder or something like the other config stuff
— Reply to this email directly, view it on GitHub https://github.com/clearlinux/distribution/issues/3215#issuecomment-2509599462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ54FIL7IUUXVGUESTTBTT2DKVQ5AVCNFSM6AAAAABSYB42IKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBZGU4TSNBWGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I retired our /usr/bin/java and put in some setting for our profile but also updated Java.
I retired our /usr/bin/java and put in some setting for our profile but also updated Java.
What release will that show up in?
What release will that show up in?
https://github.com/clearlinux-pkgs/filesystem/commit/b38fb071d8c77ef82d57c7f0c97d42b309ce7310
it's out in 42800 i believe EDIT: https://download.clearlinux.org/releases/42800/clear/RELEASENOTES
Since this does break other code can you please verify whether your problem is also resolved with the alternative setting for JAVA_HOME I proposed in https://github.com/clearlinux/distribution/issues/3250?
I am guessing this has been fixed in 42960?
I am guessing this has been fixed in 42960?
As @K1ngfish3r pointed out it was already fixed with 42800 but as I pointed out in #3250 and the comment above this fix is incorrect since it breaks other Java software. Therefore it would be great if you would try whether the alternative fix as proposed in #3250 does also solve your issue.
As @K1ngfish3r pointed out it was already fixed with 42800 but as I pointed out in #3250 and the comment above[,] this fix is incorrect since it breaks other Java software.
If it breaks something else (whatever that may be), then it has not been fixed.
Therefore it would be great if you would try whether the alternative fix as proposed in #3250 does also solve your issue.
I would rather wait until the devs themselves fix it. So far, there's no skin off my back.