//MDEPS for adding things to --module-path ?

[maxandersen]

wanted to try out nashorn 15 and seems it is impossible to run without putting it on the module-path.

Given this code:

///usr/bin/env jbang "$0" "$@" ; exit $?
//JAVA 15+
//DEPS info.picocli:picocli:4.5.0
//DEPS org.openjdk.nashorn:nashorn-core:15.0
import picocli.CommandLine;
import picocli.CommandLine.Command;
import picocli.CommandLine.Parameters;

import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;
import java.util.concurrent.Callable;

@Command(name = "js", mixinStandardHelpOptions = true, version = "js 0.1",
        description = "js made with jbang")
class js implements Callable<Integer> {

    @Parameters(index = "0", description = "The script to evaluate", defaultValue = "print('Hello, World!');")
    private String script;

    public static void main(String... args) {
        int exitCode = new CommandLine(new js()).execute(args);
        System.exit(exitCode);
    }

    @Override
    public Integer call() throws Exception { // your business logic goes here...
        // create a script engine manager
        ScriptEngineManager factory = new ScriptEngineManager();
        // create a Nashorn script engine
        ScriptEngine engine = factory.getEngineByName("nashorn");
        // evaluate JavaScript statement
        try {
            engine.eval(script);
        } catch (final ScriptException se) { se.printStackTrace(); }
        return CommandLine.ExitCode.OK;
    }
}

jbang generates something like:

 /Users/max/.jbang/cache/jdks/15/bin/java -classpath /Users/max/.jbang/cache/jars/js.java.a7d04aef6dd8094dd0e474c09e2e936e8506009e9bdceb96e238d1febc09be2e.jar --module-path /Users/max/.m2/repository/info/picocli/picocli/4.5.0/picocli-4.5.0.jar:/Users/max/.m2/repository/org/openjdk/nashorn/nashorn-core/15.0/nashorn-core-15.0.jar:/Users/max/.m2/repository/org/ow2/asm/asm/7.3.1/asm-7.3.1.jar:/Users/max/.m2/repository/org/ow2/asm/asm-commons/7.3.1/asm-commons-7.3.1.jar:/Users/max/.m2/repository/org/ow2/asm/asm-analysis/7.3.1/asm-analysis-7.3.1.jar:/Users/max/.m2/repository/org/ow2/asm/asm-tree/7.3.1/asm-tree-7.3.1.jar:/Users/max/.m2/repository/org/ow2/asm/asm-util/7.3.1/asm-util-7.3.1.jar js

with everything on classpath - this fails and nashorn is not available.

but if you change it to :

/Users/max/.jbang/cache/jdks/15/bin/java -classpath /Users/max/.jbang/cache/jars/js.java.a7d04aef6dd8094dd0e474c09e2e936e8506009e9bdceb96e238d1febc09be2e.jar:/Users/max/.m2/repository/info/picocli/picocli/4.5.0/picocli-4.5.0.jar --module-path /Users/max/.m2/repository/org/openjdk/nashorn/nashorn-core/15.0/nashorn-core-15.0.jar:/Users/max/.m2/repository/org/ow2/asm/asm/7.3.1/asm-7.3.1.jar:/Users/max/.m2/repository/org/ow2/asm/asm-commons/7.3.1/asm-commons-7.3.1.jar:/Users/max/.m2/repository/org/ow2/asm/asm-analysis/7.3.1/asm-analysis-7.3.1.jar:/Users/max/.m2/repository/org/ow2/asm/asm-tree/7.3.1/asm-tree-7.3.1.jar:/Users/max/.m2/repository/org/ow2/asm/asm-util/7.3.1/asm-util-7.3.1.jar js

the only change is inject of --module-path before the nashorn deps ...things work.

That makes me think that a simple improvement we could do is to do this:

///usr/bin/env jbang "$0" "$@" ; exit $?
//JAVA 15+
//DEPS info.picocli:picocli:4.5.0
//MDEPS org.openjdk.nashorn:nashorn-core:15.0

and let those deps found via MDEPS be fed into --module-path entry.

That would at least let things work for this case.

[koppor]

I think, I have a similar issue when updating to JDK26 (JabRef/jabref#15357)

$ jbang .jbang/JabKitLauncher.java
[jbang] Resolving dependencies...
[jbang]    org.openjfx:jdk-jsobject:26
[jbang]    org.jabref:jablib:6.0-SNAPSHOT
[jbang]    io.github.adr:e-adr:2.0.0
[jbang]    info.picocli:picocli:4.7.7
[jbang] Dependencies resolved
[jbang] Building jar for JabKitLauncher.java...
Note: C:\git-repositories\jabref\jabkit\src\main\java\org\jabref\toolkit\JabKitLauncher.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Error occurred during initialization of boot layer
java.lang.module.FindException: Module jdk.jsobject not found, required by javafx.web

///usr/bin/env jbang "$0" "$@" ; exit $?

//DESCRIPTION jabkit - mange BibTeX files using JabRef

//JAVA 26+
//DEPS org.openjfx:jdk-jsobject:26
//RUNTIME_OPTIONS --enable-native-access=ALL-UNNAMED

// mavenlocal is listed first so a locally built jablib (./gradlew :jablib:publishToMavenLocal)
// takes precedence over the published 6.0-SNAPSHOT - needed when testing unreleased jablib changes.
// raw is for https://github.com/unicode-org/icu/pull/2127
//REPOS mavenlocal,mavencentral,mavencentralsnapshots=https://central.sonatype.com/repository/maven-snapshots/,raw=https://github.com/@raw/JabRef/jabref/refs/heads/main/jablib/lib/

//DEPS org.jabref:jablib:6.0-SNAPSHOT
// see  https://github.com/gradlex-org/extra-java-module-info/issues/237 why we include e-adr here
//DEPS io.github.adr:e-adr:2.0.0

// requirements needed by jabkit projecxt need to be listed; requirements by jablib are loaded transitively
//DEPS info.picocli:picocli:4.7.7

[quintesse]

One of the easiest ways to fix this is normally to just turn your script into a module or run it as a module. (The former is done by adding //MODULE , the latter by passing the --module option to jbang).

By making these changes to the original script things will work:

//JAVA 17+
//DEPS org.openjdk.nashorn:nashorn-core:15.7
//MODULE

package test;

Now, why did the "fix" mentioned by @maxandersen in the issue description work and not when simply adding everything to the classpath? Weren't we told that you could always just add everything on the classpath without ever using modules and everything would be fine?

Well yes and no. The older Nashorn included in the JDK used the standard Service Loader system and that one would work in whatever way. But when they turned it into an independent artifact they also turned it into a full-fledged module that no longer supports Service Loaders, so it can no longer find any engines if you're not using modules. (You can instantiate it directly though)

So then we come to the point of introducing //MDEPS. At first glance it seems like an obvious solution: it's a hint by the dev that all dependencies added using //MDEPS should always be added to the --module-path. Easy peasy... right?

Well... I think there might be an issue with that. And I think you only have to look at Maven itself to see one reason: the <dependency> tags don't let you decide whether to put something on a classpath or module path either.

In the end you can only resolve everything together as a single query. There's no way to determine which transitive dependencies belong to //MDEPS artifacts and which belong to //DEPS ones (and therefore no way to determine if they should go on the -classpath or on the --module-path). And even if you could, there would be times where a dependency is used both by //MDEPS as well as a //DEPS dependency, then what? ... Well you should really be using //MODULE.

So I think the manual "fix" is neat, but I'm not sure there is a way to define this using JBang directives.

[maxandersen]

@quintesse whats the case where you don't want transitive dependencies on module classpath if we had //MDEPS ?

[quintesse]

What I mean is that you don't really know which of those transitive dependencies need to be on which path. AFAIK the Maven resolver doesn't tell which "parent" caused that transitive dependency to be pulled in.

But then I also mentioned that even if you could figure that out you would still have the problem that a transitive dependency could belong to multiple artifacts, each one of which could either be a //DEPS or an //MDEPS. Again AFAIK the only way to solve that is to make your entire app a module.

Given those issues (if I'm correct) my recommendation would be: use //MODULE the moment you get any issues related to modules.

Btw, AI agrees with me 😉

Why You Should Resist //MDEPS

The critics are entirely correct. Introducing //MDEPS opens a massive box of edge-case bugs that will haunt the JBang issue tracker.

If a user writes:

//DEPS some:classpath-lib:1.0
//MDEPS org.openjdk.nashorn:nashorn-core:15.4

And both of those libraries transitively share a common utility JAR (like org.ow2.asm:asm or com.google.guava:guava), JBang faces an impossible choice:

1. If JBang puts the shared utility on the --module-path, some:classpath-lib might lose visibility to it or experience split-package errors.
2. If JBang puts it on the --classpath, Nashorn's module structure breaks because a named module cannot read a dependency hosted on the classpath.

There is no algorithm JBang can implement to solve this dependency-sharing paradox automatically. It is a strict JVM constraint

[maxandersen]

I would treat each as separate
Resolves imo.

Shouldn't that be fine ?

[quintesse]

So how would you deal with duplicates in those resolves? And what when they are not exact duplicates, but of different versions? And what do you do if an artifact on the classpath needs to access something that's on the module path (for example it tries to do introspection or service lookups). You like AI, it says merging multiple lookups is a really bad idea ;-)

[quintesse]

Also just putting things on the module path might cause all kinds of issues that you cannot predict beforehand.
And it will probably work for a whole bunch of small tests you can create and say "see, it works", but the moment someone tries to do something more complex... for example, we might need to test things like this together with Quarkus and Spring, complex frameworks with a lot of "trickery". They might not like us playing around with the module and class paths.