在OSX jdk 1.8.0_111上打破了user.dir属性？其他操作系统，版本怎么样？ [英] user.dir property broken on OSX jdk 1.8.0_111? how about other OS, versions?

问题描述

我只有这个mac，我想知道这个问题是否存在于其他操作系统或jdks上。此测试失败，其中第二行到最后一行验证绝对路径是否引用实际文件（并匹配第一个文件abs路径）但是f2.exists调用返回false，就像它不存在一样。

I only have this mac and am wondering if this issue exists on other OS's or perhaps jdks. This test fails where the 2nd to last line verifies the absolute path is referencing a real file(and matches the first file abs path) BUT the f2.exists call returns false like it does not exist.

我对windows和linux感到好奇，如果这也失败了吗？

I am curious on windows and linux if this also fails?

@Test
public void testUserDirProp() {
    File f = new File("src/test/resources/logback-test.xml");

    //assert absolute path is correct
    Assert.assertEquals("/Library/Workflow/webpieces/core/core-util/src/test/resources/logback-test.xml", f.getAbsolutePath());
    Assert.assertTrue(f.exists());

    //NOW, change user.dir
    System.setProperty("user.dir", "/Library/Workflow/webpieces/core/core-util/src");

    //Now, f2 is relative to NEW user.dir property
    File f2 = new File("test/resources/logback-test.xml");

    //verify absolute path is still the full correct path for f2 and it is
    Assert.assertEquals("/Library/Workflow/webpieces/core/core-util/src/test/resources/logback-test.xml", f2.getAbsolutePath());

    //since absolute path was correct, it should exist 
    Assert.assertTrue(f2.exists());
}

推荐答案

user.dir 属性未被破坏。 设置不受支持，并且不保证以任何特定方式运行。请参阅 http://bugs.java.com/bugdatabase/view_bug.do?bug_id = 4117557 和链接的门票：

user.dir property isn't broken. Setting it isn't supported, and isn't guaranteed to behave in any specific way. See http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4117557 and the linked tickets:

在仔细考虑之后，我们仍然不相信当前的行为可以/应该是改变。我们从未保证在任何给定时间都会查询user.dir，不幸的是jdk假设此属性不会更改。理想情况下，我们会引入只读系统属性的概念，以防止此系统属性和其他系统属性中的不受支持的更改。

After careful consideration, we still do not believe that the current behaviour can/should be changed. We have never guaranteed that "user.dir" will be consulted at any given time and unfortunately the jdk has assumed that this property will not change. Ideally we'd introduce the concept of a "read-only" system property to guard against unsupported changes in this and other system properties.

user.dir，其中在jvm启动期间初始化，应该用作
informative / readonly系统属性，尝试通过命令行自定义它
-Duser.dir = xyz将最终执行dependend / unspecified行为。
当前的FileSystem实现在很大程度上取决于假设
我们没有chdir或chdir之类的功能（比如使用-Duser.dir = xyz）
这将改变当前用户目录不是从一个jvm启动。
也就是说，FileIn / OutputStream的不一致行为确实是一个错误的
行为（FileIn / OutputStream的open impl直接打开直接打开
而不咨询java File / FileSystem因为提到了假设
以上）。

"user.dir", which is initialized during jvm startup, should be used as an informative/readonly system property, try to customize it via command line -Duser.dir=xyz will end up at implementation dependend/unspecified behavior. The current FileSystem implementation heavily depends on the assumption that we dont have a "chdir" or "chdir" like functionality (like use -Duser.dir=xyz) that will change the "current user dir" to not the one jvm startup from. That said, the inconsistent behavior of FileIn/OutputStream is indeed a buggy behavior (FileIn/OutputStream's open impl goes down to naive open directly without consulting java File/FileSystem because of the assumption mentioned above).

要更改当前实现以支持可自定义user.dir是
a大笔交易，很多类/更改行，只有在我们相信时才这样做这是
真的值得做。

To change the current implementation to support "customizable" user.dir is a big deal, lots of classes/lines of change, only do it if we believe it's really worth doing.

这篇关于在OSX jdk 1.8.0_111上打破了user.dir属性？其他操作系统，版本怎么样？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！