JShell static imports / local classes

[juhalindfors]

Is it possible to do static imports of locally compiled classes with jsh scripts running with JBang?

Related issue/question for stand-alone JShell can be found here: https://bugs.openjdk.org/browse/JDK-8213715

Following the above advice, compiling a class with package declaration in a local directory works with JShell:

jbang/test$ jshell
|  Welcome to JShell -- Version 17.0.3
|  For an introduction type: /help intro

jshell> import static bar.Bar.foo;

jshell> foo();
Done!

Where the local directory bar/Bar.java implementation is simply defined as:

package bar;

public class Bar {
  public static void foo()  {  System.out.println("Done!"); }
}

The corresponding class file is locally under the working directory bar/Bar.class which JShell appears to pick up into its classpath automatically.

However, trying to run a jsh script via JBang results in NoClassDefFoundError.

import static bar.Bar.foo;

foo();

Exception java.lang.NoClassDefFoundError: bar/Bar
      at (#2:1)
Caused by: java.lang.ClassNotFoundException: bar.Bar
      at URLClassLoader.findClass (URLClassLoader.java:445)
      at DefaultLoaderDelegate$RemoteClassLoader.findClass (DefaultLoaderDelegate.java:154)
      at ClassLoader.loadClass (ClassLoader.java:587)
      at ClassLoader.loadClass (ClassLoader.java:520)
      ...

Have I missed something, or doing this wrong? Is this expected to work with JBang?

[quintesse]

I would try two things:

• first, what happens if your try to run the same .jsh file with jshell? (so not in interactive mode)
• second, run the jbang command with --verbose which will show us what command Jbang is executing, we can then compare it to see if there are any obvious differences

[juhalindfors]

Running the same script with jshell works as expected:

jbang/test$ jshell test.jsh 
Done!

Running with --verbose:

jbang --verbose test.jsh 
[jbang] jbang version 0.95.0
[jbang] System Java version detected as 17
[jbang] System Java version matches requested version 17
[jbang] run: jshell --execution=local -J--add-modules=ALL-SYSTEM --startup=DEFAULT --startup=/tmp/jbang_arguments_1171277589178802725test.jsh /home/juha/jbang/test/test.jsh /tmp/jbang_exit_10700339706068394666test.jsh
WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.vector
Exception java.lang.NoClassDefFoundError: bar/Bar
      at (#2:1)
Caused by: java.lang.ClassNotFoundException: bar.Bar
      at URLClassLoader.findClass (URLClassLoader.java:445)
      at DefaultLoaderDelegate$RemoteClassLoader.findClass (DefaultLoaderDelegate.java:154)
      at ClassLoader.loadClass (ClassLoader.java:587)
      at ClassLoader.loadClass (ClassLoader.java:520)
      ...

[quintesse]

@maxandersen we'll have to think what we want to do about this. It seems we either support features like this or being able to use jshell to read stdin.

Perhaps there could be a way to switch between the behaviors automatically but that could also mean a single script behaving differently (including being able to run or not) depending on how it's being used.

[maxandersen]

So we have the choice between running slowly with flexibility or decent speed and with scriptability.

I would probably choose the latter as default and explore if can find to allow enabling slow but flexible.

I wonder if custom execution engine could work around it and let input stream pass through?

[quintesse]

I would probably choose the latter as default

I understand you'd say that, but we've tweeted and written about using jbang for filtering and I think it would be a bad idea to break those.

[maxandersen]

Fast with scriptability is the one with piping input support :)

I was thinking if using -i (interaktive) would be meaningful to run in Non local?

[quintesse]

Wait really? Weren't you at other times stating that the changes to make piping work also made it start slower?

The interactive mode could indeed use non-local, but what I don't like about this is that it makes code behave differently just on how you start it. It just feels wrong, it's definitely not "least surprise". So I'm wondering if it's something that we should make explicit, like having to choose between a vanilla/basic jshell experience and the one that supports piping. With a flag of some sort. Or, if possible, we detect if input is being piped and only switch to local mode in that instance.