RFR: 8193277: SimpleFileObject inconsistency between getName and getShortName

[Jonathan Gibbons]

+1


On 03/13/2019 05:23 PM, Liam Miller-Cushon wrote:
> Thanks for the context. Proactively wrapping it sounds like a good 
> idea, I updated the change to do that:
>
> http://cr.openjdk.java.net/~cushon/8193277/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ecushon/8193277/webrev.01/>
>
> (I also filed JDK-8220634 for SymLinkArchiveTest)
>
> On Wed, Mar 13, 2019 at 4:40 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Hmmm, curious,
>
>     The src/ change is OK; all the concern is about the test, on
>     Windows, and this text in the spec:
>
>     https://docs.oracle.com/javase/9/docs/api/java/nio/file/Files.html#createSymbolicLink-java.nio.file.Path-java.nio.file.Path-java.nio.file.attribute.FileAttribute...-
>
>>     Where symbolic links are supported, but the underlying
>>     |FileStore|
>>     <https://docs.oracle.com/javase/9/docs/api/java/nio/file/FileStore.html>
>>     does not support symbolic links, then this may fail with an
>>     |IOException|
>>     <https://docs.oracle.com/javase/9/docs/api/java/io/IOException.html>.
>>     Additionally, some operating systems may require that the Java
>>     virtual machine be started with implementation specific
>>     privileges to create symbolic links, in which case this method
>>     may throw |IOException|.
>
>     That's spec-speak to cover the case that the historical perception
>     has been that (IIRC) you require admin privileges on Windows to
>     create symbolic links.
>
>     Taking a quick survey of existing tests ...
>
>     $ grep -rl Files.createSym open/test/langtools/
>     open/test/langtools/tools/javac/modules/SourceInSymlinkTest.java
>     open/test/langtools/tools/javac/file/SymLinkTest.java
>     open/test/langtools/tools/javac/file/SymLinkArchiveTest.java
>     open/test/langtools/tools/javac/links/LinksTest.java
>
>     ... I see that 3 of the 4 use something like this idiom:
>
>>             try {
>>                 Files.createSymbolicLink(lsrc, Paths.get("src"));
>>             } catch (FileSystemException fse) {
>>                 System.err.println("warning: test passes vacuously,
>>     sym-link could not be created");
>>                 System.err.println(fse.getMessage());
>>                 return;
>>             }
>
>     But SymLinkArchiveTest.java does not -- it just does a plain call
>     of Files.createSymbolicLink, and the test is not excluded (i.e.
>     listed on the ProblemList)
>
>     So, given your assertion that you get a clean build/test run, and
>     given the existence of a separate test that appears to be able to
>     create symbolic links on all platforms, I guess the test is good
>     to go.  But if any problems arise with this test, we may need to
>     wrap the call as illustrated above. Or you can proactively wrap
>     it, to be on the safe side.
>
>     -- jon
>
>
>
>     On 03/13/2019 03:46 PM, Liam Miller-Cushon wrote:
>>     Any concerns with this, as long as the tests pass on all platforms?
>>
>>     On Tue, Mar 5, 2019 at 2:36 PM Liam Miller-Cushon
>>     <cushon at google.com <mailto:cushon at google.com>> wrote:
>>
>>         The submit repo build is clean.
>>
>>         On Tue, Mar 5, 2019 at 3:30 PM Liam Miller-Cushon
>>         <cushon at google.com <mailto:cushon at google.com>> wrote:
>>
>>             On Tue, Mar 5, 2019 at 3:16 PM Jonathan Gibbons
>>             <jonathan.gibbons at oracle.com
>>             <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>                 There can be problems with symbolic links on Windows.
>>                 Have you tried the
>>                 test on a Windows system?
>>
>>
>>             Not yet, I just sent it to the submit repo.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/8c741682/attachment.html>