module result in unbuildable script

[maxandersen]

this is jbang init -t cli test.java with //MODULE and package added:

///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS info.picocli:picocli:4.6.3
//JAVA 17+
//MODULE

package mypackage;

import picocli.CommandLine;
import picocli.CommandLine.Command;
import picocli.CommandLine.Parameters;

import java.util.concurrent.Callable;

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

    @Parameters(index = "0", description = "The greeting to print", defaultValue = "World!")
    private String greeting;

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

    @Override
    public Integer call() throws Exception { // your business logic goes here...
        System.out.println("Hello " + greeting);
        return 0;
    }
}

results in:

 jbang run test.java
[jbang] Building jar...
/Users/manderse/.jbang/cache/jars/test.java.0e77c773254a8bc393c20de09d828601fd99cfca65ac3c38d9a9b8f667cbc96a/generated/module-info.java:24: error: module not found: jdk.naming.ldap
    requires jdk.naming.ldap;
                       ^
1 error
[jbang] [ERROR] Error during compile
[jbang] Run with --verbose for more details

[maxandersen]

looks like module list is generated based on the default java version rather than the target java version:

eval $(jbang jdk java-env 11) && java --list-modules | grep ldap
[email protected]
❯ eval $(jbang jdk java-env 17) && java --list-modules | grep ldap

problem is - makes the idea of having //MODULE generate deps on all modules kinda problematic as its not reliable...

[maxandersen]

seems this is a special case of weird, that module is only present in java 11:

for i in {9..17}; do echo "$i";done | xargs -I {} /bin/bash -c 'echo {}; eval $(jbang jdk java-env {} | tail -n +2) && java --list-modules | grep naming.ldap'
9
10
11
[email protected]
12
13
14
15
16
17

[maxandersen]

due to findings about it being a single rouge module I for now work around it in https://github.com/jbangdev/jbang/commit/0a5a45a557c46b50310f7b7b428e15a164ce46e8 by simply excluding this module.

will have to find some rationale for why this module is not included ..

[quintesse]

looks like module list is generated based on the default java version rather than the target java version:

Oops, that's quite an oversight on my part.

seems this is a special case of weird, that module is only present in java 11:

Actually, I had thought to only include the java. ones at first, and then thought "ah what the heck, I'll include the jdk. ones as well. But perhaps that was a bad idea and we should just limit ourselves to the java. ones?

[maxandersen]

Sounds like a plan!

[quintesse]

Ok, so after looking at it some more I was thinking that perhaps we should simply generate a small list of default imports.

My reasons are:

• the list of imports is pretty stable, only Java 9 had a different list of (java.*) modules
• most modules are actually pretty "esoteric", meaning that they are dedicated to some very specific java features
• creating a "proper" list of modules by actually asking the correct JDK for its list of modules using code adds complexity

So we could either hard-code the entire list of modules that versions 11-21 have (the list of modules in Java 9 is longer), but then we run the risk that some of the more specialized ones might be removed in the future meaning we'd have to stay alert for changes in newer Java versions.

Or we can create a curated list of what we think would be the most used modules.

Personally, if I look at the list:

java.base	
java.compiler	
java.datatransfer	
java.desktop	
java.instrument	
java.logging	
java.management	
java.management.rmi	
java.naming	
java.net.http	
java.prefs	
java.rmi	
java.scripting	
java.se	
java.security.jgss	
java.security.sasl	
java.smartcardio	
java.sql	
java.sql.rowset	
java.transaction.xa	
java.xml	
java.xml.crypto

I'd only add java.logging and perhaps java.net.http (java.base is always available, no need to add it). In all other cases people can add a module-info.java file themselves... and we could always create the possibility to express imports in the //MODULE tag in the future.

WDYT @maxandersen ?