How can I change the javacpp temp dir when launching QuPath?

Hi Peter,

we are using QuPath in a Windows domain with AD-managed user profiles on Windows. Our IT management has implemented a quota of 50 MB on the user profile directories and unfortunately javacpp puts copies of e.g. opencv there upon starting QuPath which don’t get removed on program shutdown - this regularly triggers the quota and prevents synchronizing the profile to the AD on logout if not deleted manually.

I tried setting -Dorg.bytedeco.javacpp.cachedir to %TEMP% in the JAVA_TOOL_OPTIONS envvar but this is apparently not picked up by QuPath/the JVM.

Do you know a way to set this Java system property when launching QuPath e.g. with a parameter or whether there is another way of telling javacpp to put the tempfiles somewhere else?

Thank you & best regards,
Simon

I haven’t encountered this before, but you can add JVM options to the config file within any QuPath installation (which includes things like -Xmx). Can it perhaps be set there?

Thank you, it works!

For reference: the necessary options for javacpp and javafx’ caches are
-Dorg.bytedeco.javacpp.cachedir=
-Djavafx.cachedir=

Using forward-slashes as path separator works even on Windows and is probably safer than backslashes which might be interpreted as escaping character.
Unfortunately no expansion of environment variables is possible, so using e.g. %TEMP% as path does not work.

(hint/note to self: QuPath and QuPath-console have separate config files :wink: )

Thank you & best regards,
Simon

3 Likes

Ok. I played with this a bit more and the user/env vars ARE indeed picked up by the JVM - although logging off and on again might be necessary. Nested envvar-expansion for %TEMP% is behaving strangely, though: It appears as if the JVM is not running in the current user’s context although it does pick up the user’s set of envvars on start. This leads to the interesting situation that %TEMP% in the user’s JAVA_TOOL_OPTIONS is expanded to the system var %TEMP% which is typically C:\Windows\Temp and NOT to the user var %TEMP% which is more like C:\Users\Username\AppData\Local\Temp (at least on Windows 10).
Trying to write to the system tempdir could result in an error if the user does not have the necessary privileges…
Long story short: Strange things happening with %TEMP%-expansion in JVM parameters passed via JAVA_TOOL_OPTIONS - maybe it’s best to set hard-coded paths there.
:slight_smile:

1 Like