Tracker and PATH

Help
1

I’m wondering if environment variables (like PATH) are only recognized when the Terminal/Bash is used ?

The case I have in mind is to launch via C++ the “java” binary and to rely on the PATH variable.

Unfortunately it doesn’t seem to be recognized.
As the current path like “/boot/system/lib/openjdk17/bin/java” depends on the version of java, it makes things complicated to deduce without the PATH variable.

My current workaround : as the “/bin” folder is recognized by the Tracker, I create the below symlink and everything is now OK :

ln -s /boot/system/lib/openjdk17/bin/java /boot/home/config/non-packaged/bin/java

Not sure what is the best approach for the Tracker : use the PATH as the last possibility, or it means the user must create symlinks in /boot/home/config/non-packaged/bin/, or something else I don’t know…

2

IIRC links are only created when you install jre packages but not when you install jdk.

Edit:
To allow multiple java versions to coexist , you need to install the package openjdkxxx-default to install links and to make the version xx the default version.

3

install the corresponding _default package or manage thid manually as you do now. This is to allow java versions to be co-installable.

4

Ok great !

I wasn’t aware of the “_default” package behavior

5

In macOS there’s /usr/libexec/java_home tool which can return a path of the default jdk or a specific jdk version. It’d be nice to have a similar one in Haiku, not sure atm how much effort it requires but shouldn’t be that complicated to code, since currently we have a limited set of jdks.

6

The jre can be switched out with pkgman or the graphical front-end. How many more solutions to the same problem are there?

7

That isn’t the problem here.

You can install severall packages all providing /system/bin/java, but you shouldn’t. The way the package darmon works now it will pick one at random to provide this file iirc.

Maybe we can rework this to be deterministic or configurable, then a defaults package is no longer neccesary

8

Every OpenJDK recipe properly configures the JAVA_HOME environment variable via the $dataDir/profile.d/openjdk.sh script. Are you able to access that variable in Tracker via getenv("JAVA_HOME")? If so, then just run $JAVA_HOME/bin/java .

If not, you can read it yourself from the file above. The path to the folder can be retrieved with something like:

BPathFinder::FindPaths(B_FIND_PATH_DATA_DIRECTORY, "profile.d", B_FIND_PATH_EXISTING_ONLY, paths);

Then the reviewers are gonna tell you how good or bad that approach is :grin:

1 Like
9

This is the same race condition between versions as I described above, just with a java specific extra step ; )

10

It’s not the package daemon (that will happily install all packages side by side), it’s the packagefs that will have to pick one specific file.

The defaults package is how we decided to make this configurable. Is there anything wrong with it that justifies adding a special case (and more code complexity) in packagefs?

11

Probably not. The defaults package is extra work for packagers however, but thinking about it more a packagefs aproach wouldn’t even work.

What if version 2 has a script but version 3 doesn’t in some conf.d directory? now you have two versions conflicting directly. And to solve that the directory names need to be versioned… and it’s the packagers work again. Oh well : )