RFR: 8249095: tools/javac/launcher/SourceLauncherTest.java fails on Windows

Jonathan Gibbons jjg at openjdk.java.net
Tue Oct 6 15:50:07 UTC 2020

On Fri, 2 Oct 2020 00:25:15 GMT, Kumar Srinivasan <ksrini at openjdk.org> wrote:

>> @rwestberg  prepared a script that runs various tests in GitHub Actions. But, sadly, with a recently proposed fix for
>> Windows handling (see https://github.com/openjdk/jdk/pull/437), the SourceLauncherTest is failing (the
>> testNoSourceOnClassPath sub-test): https://github.com/rwestberg/jdk/runs/1188397548
>> I don't think this has much to do with javac (or source launcher) itself - the test fails while it tries to write the
>> test source file, before the source launcher is invoked. So this patch tries to: a) avoid doing that; b)  improve
>> ToolBox to check and reject file names that are reserved.  Note that testHelloWorldWithAux uses the name "Aux"
>> intentionally, and it passes because it never actually writes file with name "Aux" - the source file will be (I
>> believe) named "HelloWorld", and while it will contain also a class named "Aux", the classfile will only ever exist in
>> memory, and won't be written as a file, so will not cause the issue.  The use of name "Aux" in the
>> testNoSourceOnClassPath test does not seem to be necessary, and the issue happens in the test set-up, not while doing
>> the actual test, so it seems fine to change the name.  @jonathan-gibbons, could you please take a look? Thanks!
> Hi Jan, thanks for the summary, that was my take as well, when I observed this issue. After reading Robin's
> evaluation,  I now understand why we discovered this problem at VMware, I am using "jtreg -xml:verify ....." which
> produces the right results in Jenkins.  I will let Jon approve this, I am ok with the fix.

I like the changes to `ToolBox`, but I am concerned that we do not understand why the problem has not shown up before.
I get that @rwestberg has added new ways to run tests, but we've been running this test on Windows internally within
Oracle for a long time now. I guess maybe it could be a characteristic of the underlying (version of) the OS and/or
file system.


PR: https://git.openjdk.java.net/jdk/pull/456

More information about the compiler-dev mailing list