Describe the bug
When any -J argument is passed on the command line (e.g.
-J-Duser.home=...), the launcher stops applying JVM arguments saved
via the Configure GUI (settings.json's jvmArguments array) to the
forked/launched client process. Only the explicit -J flag(s) passed
on the command line take effect; configured jvmArguments are silently
dropped rather than merged with the command-line ones.
To Reproduce
- Run
--configure, set JVM arguments to e.g. -Xmx2048m,
-Xms2048m.
- Confirm settings.json's
jvmArguments contains those values.
- Launch RuneLite via any wrapper/launcher that passes an unrelated
-J flag on the command line — e.g. -J-Duser.home=/some/path
(this is how third-party launchers such as Bolt invoke it).
- Inspect the running client process (
ps -ef) — the configured
jvmArguments are absent; only the explicit command-line -J flag
is present.
Expected behavior
JVM arguments saved via the Configure GUI should still apply even
when other -J flags are present on the command line — merged
together rather than one fully overriding the other.
Environment
- RuneLite client version: 1.12.33
- Originally surfaced via Bolt (third-party Linux launcher); traced
and confirmed by Bolt's maintainer as launcher-side behavior:
https://codeberg.org/Adamcake/Bolt/issues/78
- OS: Linux (Nobara/Fedora-based), though the mechanism described
appears OS-independent
Additional context
Quoting Bolt's maintainer's diagnosis: "RuneLite seems to ignore the
extra jvm arguments if any -J args are passed on the command line,
since command line is usually supposed to override config."
Workaround confirmed effective: manually appending
-J-Xmx2048m -J-Xms2048m -J-XX:MaxGCPauseMillis=15 after an existing
-J-Duser.home=... flag causes the client to correctly receive and
honor the additional arguments (verified via ps -ef showing them in
the running process).
Describe the bug
When any
-Jargument is passed on the command line (e.g.-J-Duser.home=...), the launcher stops applying JVM arguments savedvia the Configure GUI (settings.json's
jvmArgumentsarray) to theforked/launched client process. Only the explicit
-Jflag(s) passedon the command line take effect; configured jvmArguments are silently
dropped rather than merged with the command-line ones.
To Reproduce
--configure, set JVM arguments to e.g.-Xmx2048m,-Xms2048m.jvmArgumentscontains those values.-Jflag on the command line — e.g.-J-Duser.home=/some/path(this is how third-party launchers such as Bolt invoke it).
ps -ef) — the configuredjvmArguments are absent; only the explicit command-line
-Jflagis present.
Expected behavior
JVM arguments saved via the Configure GUI should still apply even
when other
-Jflags are present on the command line — mergedtogether rather than one fully overriding the other.
Environment
and confirmed by Bolt's maintainer as launcher-side behavior:
https://codeberg.org/Adamcake/Bolt/issues/78
appears OS-independent
Additional context
Quoting Bolt's maintainer's diagnosis: "RuneLite seems to ignore the
extra jvm arguments if any -J args are passed on the command line,
since command line is usually supposed to override config."
Workaround confirmed effective: manually appending
-J-Xmx2048m -J-Xms2048m -J-XX:MaxGCPauseMillis=15after an existing-J-Duser.home=...flag causes the client to correctly receive andhonor the additional arguments (verified via ps -ef showing them in
the running process).