Options in JBANG_APP_JAVA_OPTIONS are duplicated for every file referenced in //SOURCES

[wfouche]

To reproduce:

set JBANG_APP_JAVA_OPTIONS=-Xms1g -Xmx2g -XX:+UseZGC
jbang run JvmRuntimeOpts.java

--- 🚀 JVM Runtime Options (VM Arguments) ---
Option 1: -Xms1g
Option 2: -Xmx2g
Option 3: -XX:+UseZGC
Option 4: -Xms1g
Option 5: -Xmx2g
Option 6: -XX:+UseZGC
Option 7: -Xms1g
Option 8: -Xmx2g
Option 9: -XX:+UseZGC
Option 10: --enable-preview

A.java

class A {}

B.java

class B {}

JvmRuntimeOpts.java

//PREVIEW 
//SOURCES A.java B.java
import java.lang.management.ManagementFactory;
import java.util.List;

/**
 * JvmRuntimeOps.java
 * This program demonstrates how to retrieve and display:
 * 1. JVM Runtime Options (VM arguments).
 * 2. Application Arguments (arguments passed to the main method).
 */
public class JvmRuntimeOpts {

    public static void main(String[] args) {
        // --- 1. Display JVM Runtime Options ---
        System.out.println("--- 🚀 JVM Runtime Options (VM Arguments) ---");

        // Use the ManagementFactory to get the RuntimeMXBean
        List<String> jvmArgs = ManagementFactory.getRuntimeMXBean().getInputArguments();

        if (jvmArgs.isEmpty()) {
            System.out.println("No explicit JVM Runtime Options found (default settings are in use).");
        } else {
            for (int i = 0; i < jvmArgs.size(); i++) {
                System.out.println("Option " + (i + 1) + ": " + jvmArgs.get(i));
            }
        }

        System.out.println("\n" + "--- 📝 Application Arguments ---");

        // --- 2. Display Application Arguments ---
        if (args.length == 0) {
            System.out.println("No Application Arguments were passed to the main method.");
        } else {
            for (int i = 0; i < args.length; i++) {
                System.out.println("Argument " + (i + 1) + ": " + args[i]);
            }
        }

        System.out.println("\n" + "--- ✅ Execution Complete ---");
    }
}

[maxandersen]

Issue here is that the env is looked up everytime. It should just be done once and merged. I think we lost explicit ordering in the refactor from a while ago which this is another variation of. See the the //JAVa order issue too.

We lacked tests of it so we didn't notice :/

[quintesse]

I again refuse to take responsibility unless you can show this didn't happen before 😁

In fact I wouldn't be surprised we had this problem all along. Because it's not something you'd normally notice. AFAIK you can add multiple duplicate java options to the command line without any issue.

And it even makes somewhat sense, all files are asked for their list of directives. At the source file level we don't know if we're the first file or the 100th, so if someone asks is your //CDS directive set? We check the file and afterwards the ENV var and we report what we find.

You could say, well, we move that somewhere at the start or at the end and we only ask for that ENV var once. Yes, but "outside" of the source file we don't know what ENV var to look for, it's the source file that has that information (think that for example Kotlin and Groovy files have their own directives, something we can't know outside of those classes).

So looking at the code it's unfortunately not immediately obvious how best to fix this (and I really doubt it was working right before).

One way would be to limit the lookup of env vars to the "first" file somehow (I fear it would be something ugly, like passing a boolean apply/don't apply env vars). But I'm not sure if we would still have ordering issues where we first apply the directives of the main source file, then the ones from the ENV vars and then any directives from any included sources. So, not sure that's the best way.

[maxandersen]

I again refuse to take responsibility unless you can show this didn't happen before 😁

not blaming anyone - and yes I think this variant of it was there since forever. The "lookup in env" for all source files just aint right. It should be done once and be considered higher importance than whats in the sources. Just follow the conventional config override mechanism: defaults < config file < sources < environment variables < command line flags

[quintesse]

Just follow the conventional config override mechanism

Yeah, that would be nice if that would always work. But like I explained earlier, there are some directives that are only known by their Source implementations (eg KotlinSource) which is 3) in your list, environment variables would be at 4) and at that level they don't know about those extra/non-standard directives.

Although now that I think about it... we don't have command line options to override those either... so perhaps we just shouldn't care about those non-standard/non-basic directives? Then it wouldn't be so hard to implement.