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

[Jonathan Gibbons]

On 8/21/24 6:35 AM, Eirik Bjørsnøs wrote:
>
> Consider the following scenario where a valid Java source file is 
> compiled in a directory containing a sibling file with a colon in its 
> file name:
>
> Z:\>dir /B
> file:txt
> HelloWorld.java
>
> Compilation fails as follows:
>
> Z:\>javac HelloWorld.java
> HelloWorld.java:1: error: cannot access unnamed package
> public class HelloWorld {
> ^
>   error accessing directory 
> Z:\invalid-pathjava.nio.file.InvalidPathException: Illegal char <:> at 
> index 4: file:txt
> 1 error
> printing javac parameters to: Z:\invalid-path\javac.20240821_151610.args
>
> The "error accessing directory" message seems to have been introduced 
> in JDK-8177332.
>
> The root exception seems to be thrown in WindowsPathParser.normalize.
>
> Questions:
>
> o Is this kind of failure expected according to the JLS and/or common 
> sense?

The JLS says very little about the host system that may be used to 
compile a program.
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.


> 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`


> 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?

Yes.


>
> Cheers,
> Eirik.