JEP 458: Launch Multi-File Source-Code Program: Inferring the root of the source tree

[Attila Kelemen]

I have a problem with the last point (the error). Because I'm trying to
imagine when would someone put the main class into a package, if the goal
is to just edit java files directly, and run them without explicit
compilation from the command line. It seems to me that it would be just
masochistic. One reason I can imagine someone has packages is if this
direct java usage is done as a temporary measure, and actually sources were
copied from a "normal" code base. In this case however, it would feel awful
to type in the long package path (which in normal package naming convention
is often tediously long), I would just want to trim the common package
prefix from the path.

So, what I would find a more convenient behaviour, if java can't unwind the
full package, then just assumes that directory is the root (up to the point
it could unwind), and all files under it have the unmatched package prefix.
For example, if I do `java dir/b/c/C.java`, and `C.java` declares its
package to be `a.b.c`, then `dir` is the root directory, and if it needs
the class `a.b.d.X`, then it would search it in `dir/b/d/X.java`.

In fact, I would love if I didn't have to create these deeply nested
directories in normal projects as well, but that is pretty much only on
IDEs (that is they behave awkwardly, if you try to do this), because -
using Gradle for example - the build tool will just list all the individual
java files to javac anyway, and at that point javac couldn't care less
about directories, and the build works fine.

Attila

Ron Pressler <ron.pressler at oracle.com> ezt írta (időpont: 2023. okt. 19.,
Cs, 23:47):

> JEP 458: Launch Multi-File Source-Code Programs (
> https://openjdk.org/jeps/458) describes a mechanism by which the root of
> a source directory is computed (for the purpose of locating other
> referenced classes) from the path of the launched file and its directory;
> that root is then used implicitly as if `--source-path <root>` has been
> passed to javac. The algorithm for inferring the source compares the .java
> file’s package against its filesystem path and “subtracts” the package from
> the suffix of the filesystem path.
>
> For example, if in directory dir/a/b/c I have the file C.java and I launch
> it as a program with `java dir/a/b/c/C.java` then:
>
> - If C.java declares its package to be a.b.c then the root of the source
> tree is inferred to be dir
> - If C.java declares its package to be b.c then the root of the source
> tree is inferred to be dir/a
> - If C.java declares its package to be c then the root of the source tree
> is inferred to be dir/a/b
> - If C.java doesn’t declare a package (i.e. it’s in the unnamed package),
> then the root of the source tree is inferred to be dir/a/b/c
> - If C.java declares its package to be p (which doesn’t match any suffix
> of its path), then we get an error.
>
> The current working directory from which we invoke `java` is ignored.
>
> This is different from the way javac behaves. If we run `javac
> dir/a/b/c/C.java`, then, for the purpose of resolving other referenced
> classes, the root of the tree is always the current working directory, and
> the package that C.java declares is ignored (it can be p and the
> compilation will succeed).
>
> The algorithm for inferring the root of the source tree in the source-code
> launcher was chosen so that programs could be easily launched directly from
> source from any working directory without explicitly setting a source tree
> root, under the reasonable assumption that source files are placed as we
> would expect in a project. I would like to get some feedback about the
> algorithm’s suitability and reasonableness.
>
> — Ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231020/a7a78042/attachment-0001.htm>