<div dir="ltr"><div>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.</div><div><br></div><div>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`.</div><div><br></div><div>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.</div><div><br></div><div>Attila</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> ezt írta (időpont: 2023. okt. 19., Cs, 23:47):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">JEP 458: Launch Multi-File Source-Code Programs (<a href="https://openjdk.org/jeps/458" rel="noreferrer" target="_blank">https://openjdk.org/jeps/458</a>) 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.<br>
<br>
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:<br>
<br>
- If C.java declares its package to be a.b.c then the root of the source tree is inferred to be dir<br>
- If C.java declares its package to be b.c then the root of the source tree is inferred to be dir/a<br>
- If C.java declares its package to be c then the root of the source tree is inferred to be dir/a/b<br>
- 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<br>
- If C.java declares its package to be p (which doesn’t match any suffix of its path), then we get an error.<br>
<br>
The current working directory from which we invoke `java` is ignored.<br>
<br>
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).<br>
<br>
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.<br>
<br>
— Ron<br>
<br>
<br>
</blockquote></div></div>