jbangdev
derived sourcepath from package like java 25
What is sourcepath notion? its that when javac runs, and sees references to a class, i.e. my.pack.Awesome it will search for that in the following way (you can run javac --verbose to verify), first it will look in the source (search) path which by default is . and then it will look in class (search) path which by default is /Users/max/Library/Java/JavaVirtualMachines/temurin-21.0.7/Contents/Home/lib/modules,. ....if nothing found THEN it will look for .class files in the class (search) path.
Yes, javac will look for .java files in classpath. its kinda spooky but it does :)
Until now in jbang we lets javac do its thing and dont adjust source path.
Now, with java introducing support for single source files in java 11 (i.e. java some.java) it did not allow multiple source files, i.e. it would not locate .java files next to it that was referenced. Its as if java single source has no sourcepath (its not 100% correct but lets just call it that)
Now in Java 25 java (not javac) when running single source files it allows multiple source files - and it does that with a little bit of "jbang style magic" :) - it uses the package name of the source ref to define what becomes the sourcepath behind the scenes. Allowing for multiple source files.
Since jbang always uses javac we didn't have the same limit IFF you run jbang in the same dir as where the .java files are.
If you start putting them in sub dirs and do things like jbang src/main/myapp.java you hit issues.
We originally solved that by introducing //SOURCES that lets you drag in arbitrary sources; including from local dir.
Now, my suggestion about source-path in its base form is to do as Java 25 does, and define source-path based on package name used in sourceref and explicitly pass that to javac -sourcepath. This would be somewhat of a minor breaking change; but its a breaking change in Java 25 too but its truly minor and the gain is that you do not need //SOURCES to guarantee what a java 25 multisource example can do ...jbang would do it for any java version though - for consistency. One caveat is that this only works for local examples - will still need //SOURCES to have remote paths resolved.
An addendum here would be to allow //SOURCEPATH and as a flag to expose this useful feature available in javac since dawn of time.
I initially considered having //SOURCES use source-path to locate its sources (why I stated replace //SOURCEPATH with //BASE) - but typing this out I realize how would that becomes tricky when we have //SOURCES **/*.java ...would we iterate all source-paths here?
the gain is that you do not need //SOURCES
I do want to point out that this would break any remote usage of scripts, they would no longer be able to find their dependent files.
We already have this somewhat with //SOURCES **/*.java but there I always had the hope that we'd be able to implement support for globbing, at least for sources like GitHub (which probably account for >99% of the cases)
@quintesse yes, it wont help for remote usage - but this fix won't change that. its already the case.