Respect `JAVA_HOME` inside start up script

[catap]

Respect `JAVA_HOME` inside start up script

[easye]

The hard-coding of the JDK used in the compilation for the abcl/abcl.bat wrapper scripts was a deliberate choice for simplicity of implementation.

Background

• the wrapper scripts were intended for development, so use of the compiling JDK was a natural choice. It was anticipated that packaging systems would write their own shims for locating an appropriate JVM. For the ABCL binary releases we don't provide any shim.

• most other wrapper scripts are rather complicated in their logic. The mvn script runs to some 200 lines of bash scripting (admittedly with comments) but covers a lot of edge cases (interaction with CLASSPATH settings, path differences when running on MSFT Windows under Cygwin)

• testing for the many differing operating system/shell combination situations gets complicated pretty quickly, and probably always going to have weird edge cases, so it was easier to punt the maintenance downstream. I decided that I would rather spend my time improving the ABCL implementation itself, and leaving it to system packagers how to chose the invoking JVM.

• Does a user really expect that if they specify a java which can be found in their PATH, that a differing value of JAVA_HOME would mean a different JVM invocation? One may answer "yes, of course, that's what JAVA_HOME means!" but I have seen systems set up/shipped where this isn't the expectation

• even if we just picked "a) BASH under a UNIX and b) cmd.exe under a shipping MSFT Windows" as the two environments to support, the differences between the shells esp. in how paths are treated is different enough to require separate testing for each environment

Offer

All that being said, if someone were to provide patches for Unix Bash/MS-DOS implementation that was more sophisticated, I would seriously consider including it. Bonus points if one has a single base template that "(com/trans)piles into" Bash/MS-DOS scripts.

[cooljeanius]

So I'm coming here from macports/macports-ports#21762 to mention that this is indirectly preventing me from upgrading abcl in MacPorts, btw... hardcoding the JDK means that the port has to use OpenJDK21, which fails to build for me currently due to: https://trac.macports.org/ticket/69440

[alanruttenberg]

I have a more sophisticated launcher but it is partially out of date and undocumented. Still, if it looks useful I will consider putting some time into it if there are opinions about what the functionality should be: https://github.com/alanruttenberg/lsw2/blob/owlapiv4/bin/abcl
Among other things it just calls plain java, which should respect JAVA_HOME, but that can also be overridden by providing ABCL_JAVA environment variable.

[catap]

On Mon, 04 Mar 2024 02:56:23 +0100, Alan Ruttenberg wrote: I have a more sophisticated launcher but it is partially out of date and undocumented. Still, if it looks useful I will consider putting some time into it if there are opinions about what the functionality should be: https://github.com/alanruttenberg/lsw2/blob/owlapiv4/bin/abcl Among other things it just calls plain java, which should respect JAVA_HOME, but that can also be overridden by providing ABCL_JAVA environment variable.

What a nice and huge job which may help, indeed. Anyway, you have an assumption that java binary is available inside PATH and it isn't true for some system. As far as I know only macOS has java wrapper inside PATH.

…

-- wbr, Kirill

[easye]

Just to emphasize: I'm happy to accept patches for this functionality, but we would need to have equivalent (and tested) functionality under Windows which is what makes this more difficult than it should be.

I use https://github.com/jenv/jenv to manage my Java runtimes. Maybe it has a Windows equivalent?

[alanruttenberg]

I'm afraid I don't know anything about running in a windows environment or how to drive any of the windows shells.