Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect JAVA_HOME inside start up script #649

Open
catap opened this issue Dec 13, 2023 · 6 comments
Open

Respect JAVA_HOME inside start up script #649

catap opened this issue Dec 13, 2023 · 6 comments

Comments

@catap
Copy link

catap commented Dec 13, 2023

This is quite usual for Java application to use JVM which is defined via JAVA_HOME environment variable.

Unfortently, abcl caches the used java at compiling time, which may lead to broken abcl when JDK is updated.

Shall it respect JAVA_HOME and simple run java by default instead like it does maven and all other projects?

@easye
Copy link
Collaborator

easye commented Dec 14, 2023

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
Copy link

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
Copy link
Collaborator

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
Copy link
Author

catap commented Mar 4, 2024 via email

@easye
Copy link
Collaborator

easye commented Mar 4, 2024

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
Copy link
Collaborator

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

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

No branches or pull requests

4 participants