Compilation fails on Windows when a sibling file name contains illegal char":"

[Eirik Bjørsnøs]

On Thu, Aug 22, 2024 at 12:58 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

As for common sense, maybe, but maybe not. It is effectively impossible
> to anticipate all the quirks of all the file systems that may be
> encountered while compiling a program. That being said, it is arguable
> that `javac` should ignore any files that are not the well-formed
> filename of a valid Java class.
>

Thanks Jonathan. I did wonder a bit why the file scanning was including all
file types in this context. (fileKinds includes
JavaFileObject.Kind.OTHER).


> > o If yes, would it be worthwhile to improve the error reporting?
> > "Cannot access unnamed package" is not super helpful, "error accessing
> > directory" is also somewhat vague.
> Well, you did get a very helpful and very specific error message ....
> `Illegal char <:> at index 4: file:txt`
>

Yes, that last part was indeed helpful in diagnosing the problem at the
implementation level.

While this is probably unlikely to happen in any properly organized,
version controlled code base, experimental code using JEP-330 might be more
likely to stumble upon it. This was what happened to me when I discovered
this while using "java HelloWorld.java" in some scratch directory
containing some oddly named, partially downloaded files.


> > o At the very least, should we add a space in the IOException message
> > thrown by DirectoryContainer.list, to separate the file path from
> > the InvalidPathException toString?
>

I filed JDK-8338815 to track this trivial enhancement, and will follow up
with a PR shortly.

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240822/cfadae55/attachment.htm>