JDK-8249095 : tools/javac/launcher/SourceLauncherTest.java fails on Windows
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 11
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2020-07-08
  • Updated: 2021-08-06
  • Resolved: 2020-10-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 16
11.0.13Fixed 16 b19Fixed
Related Reports
Relates :  
Description
On Windows the test tools/javac/launcher/SourceLauncherTest.java fails.
This is due to a perennial problem, and manifests when a file is created with a Windows reserved names, please see the following:
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#file_and_directory_names

The error is this:
https://hg.openjdk.java.net/jdk/jdk/file/c1f532e5f910/test/langtools/tools/javac/launcher/SourceLauncherTest.java#l428

Exception running test testNoSourceOnClassPath: java.nio.file.NoSuchFileException: testNoSourceOnClassPath\auxSrc\Aux.java
java.nio.file.NoSuchFileException: testNoSourceOnClassPath\auxSrc\Aux.java
        at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:85)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
        at java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:235)
        at java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:478)
        at java.base/java.nio.file.Files.newOutputStream(Files.java:219)
        at java.base/java.nio.file.Files.newBufferedWriter(Files.java:2919)
        at java.base/java.nio.file.Files.newBufferedWriter(Files.java:2962)
        at toolbox.ToolBox$JavaSource.write(ToolBox.java:636)
        at toolbox.ToolBox.writeJavaFiles(ToolBox.java:565)
        at SourceLauncherTest.testNoSourceOnClassPath(SourceLauncherTest.java:269)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at toolbox.TestRunner.runTests(TestRunner.java:89)
        at SourceLauncherTest.main(SourceLauncherTest.java:63)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:834)

Here is an example using java source launcher:

$ cat Test.java
import java.io.*;
import java.nio.file.*;
public class Test {
    public static void main(String... args) throws Exception {
	if (args == null || args.length < 1) {
            throw new Error("Usage: need one pathspec argument");
	}
        Path file = Path.of(args[0]);
	Files.createDirectories(file.getParent());
	try (BufferedWriter out = Files.newBufferedWriter(file)) {
            out.write("An auk or alcid is a bird of the family of Alcidae.");
	}
    }
}

$ BLAH/images/jdk/bin/java Test.java  foo/Aux.java
Exception in thread "main" java.nio.file.NoSuchFileException: foo\Aux.java
        at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:85)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
        at java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:235)
        at java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:478)
        at java.base/java.nio.file.Files.newOutputStream(Files.java:219)
        at java.base/java.nio.file.Files.newBufferedWriter(Files.java:2919)
        at java.base/java.nio.file.Files.newBufferedWriter(Files.java:2962)
        at Test.main(Test.java:16)

$ BLAH/images/jdk/bin/java Test.java  foo/Auk.java
$ cat foo/Auk.java
An auk or alcid is a bird of the family of Alcidae.


So changing the name from Aux.java or class Aux to Auk will work for the test. I am not sure why javac did not catch this please see JDK-6241975.

I discovered this with jdk11.0.8 and why hasn't anyone else encountered this issue ?

My suggestion is to enhance toolbox and other test helpers to check for these reserved keywords and warn the developer up front.

Running on Windows Server 2016.

Comments
Fix request (11u): Please approve the clean backport of this text fix. The issue poped up in GitHub Actions workflow every time I tested, so we should have it to reduce noise.
05-08-2021

Changeset: cd4faff0 Author: Jan Lahoda <jlahoda@openjdk.org> Date: 2020-10-07 06:52:03 +0000 URL: https://git.openjdk.java.net/jdk/commit/cd4faff0
07-10-2020

Although I don't (yet) understand why the test is failing for you but not for us, my local experiments seem to indicate that it is not passing as expected for us ... yes it passes, but maybe for the wrong reasons. With this in mind, it is definitely reasonable to update the toolbox classes to include an optional default-on check for the use of any problem names on any platforms. (i.e. the warning would not be limited to being activated on specific platforms.) If there are any use cases to warn to try and write such files, the warning could be temporarily disabled. Separately, I guess we should revisit the issue of javac trying to write these classes, although there I'm more inclined to make it a platform-specific warning, so that writing Aux.class is OK on Linux but not on Windows (for example.)
09-07-2020

Understood that the test case that is failing for you is testNoSourceOnClassPath. I'm just looking at other test cases in this file which all seem to work in our test runs. So, I'm still looking for reasons why this test is failing for you and not for anyone else.
09-07-2020

Wait, the test that is failing for me is testNoSourceOnClassPath not testHelloWorldWithAux. But according to JDK-6241975 should javac have warned me ? $ cat TestInner.java class TestInner {} class Aux {} $ LONG_PATH/jdk/bin/javac -Xlint TestInner.java TestInner.java:2: error: error while writing Aux: C:\cygwin64\tmp\AOT\Aux.class class Aux {} ^ 1 error $ fsutil fsinfo ntfsinfo d: | grep Version NTFS Version : 3.1 LFS Version : 2.0 Please note: I double checked both c: and d: are the same versions.
08-07-2020

brainstorming possibilities ... what kind of filesystem are you using when running the tests?
08-07-2020

And, to be clear, this test is not on the exclude list for test/langtools and is a :tier1 test so it is executed regularly on all platforms,
08-07-2020

If this issue is to be addressed, it should also be addressed in javac: JavacFileManager ... and not just in ToolBox/etc
08-07-2020

I think the question here is wrongly focussed. I think the intent of the code *is* to use the name "Aux" -- there's no other reason for that name to be chosen ... see line 107, and "testHelloWorldWithAux". So, the question should really be, why is it working on Oracle CI systems, and not for others?
08-07-2020