In recent JDKs I see that JAVA_ARGS is never undefined, e.g. When the "java" executable is built, main.c is compiled with
 -DJAVA_ARGS='{ "-J-ms8m", }'
but historically JAVA_ARGS was undefined in the "java" launcher, and there are various comments in the sources guaranteeing this, e.g.

 * If JAVA_ARGS is defined, then acts as a launcher for applications. For
 * instance, the JDK command line tools such as javac and javadoc (see
 * makefiles for more details) are built with this program. Any arguments
 * prefixed with '-J' will be passed directly to the 'java' command.

There are various misleading symbols in the launcher source that should be fixed:
jboolean javaargs
IsJavaArgs()
_is_java_args

---

In any case, it is surprising for the launcher to pass any hidden JVM flags to the JVM. It's the JVM's job to select reasonable defaults for minimum heap size, not the launcher's, at least for "java". (Users might have written their own launcher)

---

The existence of both JAVA_ARGS and EXTRA_JAVA_ARGS is pretty confusing. It looks like this is a terrible hack to get around some old Windows compiler limitation. We should delete the hack or perhaps write the definition of the JAVA_ARGS to some generated header file.

I see this code:

        main_jargc = (sizeof(const_jargs) / sizeof(char *)) > 1
            ? sizeof(const_jargs) / sizeof(char *)
            : 0; // ignore the null terminator index

where the comment is deeply misleadingly because const_jargs is __NOT__ null terminated and sizeof(const_jargs) is never 0. OTOH if EXTRA_JAVA_ARGS is defined, then the merged argv *****IS**** null terminated!

            // terminate the list
            JLI_List_add(list, NULL);

All of this code is super brittle and will break if JAVA_ARGS ever acquires another flag.