Hey there headius, enebo etc.. and everyone else,

Some time ago I reported that minor notification:

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::arrayBaseOffset has been called by org.jruby.util.StringSupport (file:/usr/lib/jruby.jar)
WARNING: Please consider reporting this to the maintainers of class org.jruby.util.StringSupport
WARNING: sun.misc.Unsafe::arrayBaseOffset will be removed in a future release
jruby 9.4.12.0 (3.1.4) 2025-02-11 f4ab75096a Java HotSpot(TM) 64-Bit Server VM 24+36-jvmci-b01 on 24+36-    jvmci-b01 +jit [x86_64-linux]

As far as I could tell it was harmless, but still different to the prior jruby release where this was not shown (even if this may have been due to my host system).

So the above was for jruby 9.4.12.x. I recently read that jruby 10.x is out so I tested it. So I can confirm that this message is now gone - but, interestingly, a new tiny thing is now reported,
though it is unrelated to the above I think. :)

Let me show you what the same command now reports to me on jruby 10.x:

/home/Programs/Graalvm/24/release: line 11: {commit.committer:: command not found
/usr/bin/jruby: line 532: [: : integer expression expected
/usr/bin/jruby: line 541: [: : integer expression expected
/usr/bin/jruby: line 552: [: : integer expression expected
/usr/bin/jruby: line 560: [: : integer expression expected
/usr/bin/jruby: line 568: [: : integer expression expected
jruby 10.0.0.0 (3.4.2) 2025-04-13 6ed59bc847 Java HotSpot(TM) 64-Bit Server VM 24+36-jvmci-b01 on 24+36-    jvmci-b01 [x86_64-linux]

I'll explain in a moment how this happens (or at the least how I think this may happen), but notice that from the above, it seems to me as if the file called "release" is queried by jruby somehow.

In other words: on my system there is indeed a file called:

/home/Programs/Graalvm/24/release

My java version is, since perhaps 2 years, coming from the Graalvm team, so I just download their releases; I like GraalVM, so I kind of use their releases. I use an unusual directory layout on my linux system, a bit similar to GoboLinux, so I have versioned AppDirs; in this context /home/Programs/Graalvm/24/ for graalvm version 24, and for jruby I would right now use: /home/Programs/Jruby/10.0.0.0/ (and the older jruby releases are also there, e. g. some of the 9.2.x releases).

A symlink points to the current version, a bit similar to how stow works (and I think also
homebrew package manager, just that they use /usr/Cellar/ or something like that; NixOS
also uses versioning, but they version a hash for the directory name instead. Anyway).

What I found interesting was that the very same command, for two different jruby versions,
returned different results. In particular I asked myself "why is the file called release checked?".

I then tested what happens when I rename that file release, to e. g. "old_release". Then I did
jrubyv again (this is my alias for jruby --version).

Interestingly this reported no error at all!

jruby 10.0.0.0 (3.4.2) 2025-04-13 6ed59bc847 Java HotSpot(TM) 64-Bit Server VM 24+36-jvmci-b01 on 24+36-jvmci-b01 [x86_64-linux]

So, without having looked at the source code, I believe some behaviour in jruby may have
been changed between 9.4.x and 10.x in this regard; and that jruby tries to happily read
a hardcoded file named "release". Naturally the logical thing to think here is that jruby
release must come with a file called "release". So I had a look but could not find a file called
"release". So now I am a bit confused why the file called "release" is checked via jruby.

As said, when I remove that file (I don't need it anyway, I think; I usually just extract the
downloadable release and not worry about anything but try to get things to run), it all
is fine, but I would still reason that the behaviour of jruby may not be absolutely correct.

I should also say that the "jruby" binary for me is a symlink at /usr/bin/jruby/, which points
at the current symlink, e. g. in my situation "/home/Programs/Jruby/Current/bin/jruby",
which is where the jruby binary resides on my computer system. Still, I don't entirely
understand why the file called "release" is checked; and why this happens on another
path, e. g. under /home/Programs/Graalvm/24/release. I could be wrong, but at the
least I can not see the primary rationale as to why, on my setup, "release" should be
read in. (It could also in theory perhaps allow others to place a wrong file called
"release" and execute code, though this is probably such a tiny assumption to not be
true; still, perhaps the logic behind checking for a file called "release", could be checked.
At first I thought because jruby itself checks for such a file, but instead the graalvm
path is checked, so perhaps this is a problem in GraalVM. In that case, I think this issue
here can be closed. Either way I'll report this here just for information - the older problem
is now gone, and the issue here may not be jruby's fault either, and is trivial to fix anyway
as I don't need the file called "release", I think. After I removed it "java" also still works fine -
not even sure why that file is packed in the base directory of the downloadable archive,
I usually am lazy and just do a recursive copy, that's why these files also end up in the
base directory of e. g. /home/Programs/Graalvm/Current/. Thanks for reading!).