代码之家  ›  专栏  ›  技术社区  ›  Tom Tresansky

为什么没有String.Empty 在爪哇?

  •  216
  • Tom Tresansky  · 技术社区  · 15 年前

    我知道每次我输入字符串文字 "" ,字符串池中引用了相同的字符串对象。

    但是为什么stringapi不包含 public static final String Empty = ""; String.Empty ?

    10 回复  |  直到 5 年前
        1
  •  200
  •   Noel M    15 年前

    String.EMPTY 是12个字符,并且 "" 是2,它们在运行时都会引用内存中完全相同的实例。我不太清楚为什么 String.EMPTY 会节省编译时间,事实上我认为是后者。

    特别是考虑 String StringBuilder (或 StringBuffer 如果你想线程安全)并把它变成一个字符串。


    从你的评论到问题:

    TextBox.setText("");

    我相信在你合适的班级里提供一个常数是完全合理的:

    private static final String EMPTY_STRING = "";
    

    TextBox.setText(EMPTY_STRING);
    

    这样至少可以明确表示您想要一个空字符串,而不是忘记在IDE或类似的东西中填充字符串。

        2
  •  153
  •   Vadim Kotov First Zero    6 年前

    org.apache.commons.lang.StringUtils.EMPTY

        3
  •  30
  •   Peter Lawrey    15 年前

    if ("".equals(text))
    

    最终你应该做你认为最清楚的事情。大多数程序员认为“”表示空字符串,而不是有人忘记输入任何内容的字符串。

    这听起来像是你在试图解决一个问题,而这个问题在15年前语言被设计出来时就已经解决了。

        4
  •  9
  •   Benoit Courtine    15 年前

    如果你真的想String.EMPTY 常量,您可以在项目中创建名为“Constants”的实用程序静态final类(例如)。这个类将维护你的常量,包括空字符串。。。

    for(int i=Constants.ZERO; ...) {
        if(myArray.length > Constants.ONE) {
            System.out.println("More than one element");
        }
    }
    

    等。

        5
  •  9
  •   Slawomir    7 年前

    对称性 没有它,API就很难用于人类。众所周知,早期的javasdk忽视了这一规则,现在已经太晚了。下面是我脑海中的几个例子,请随意插入您“最喜欢”的例子:

    • BigDecimal.ZERO,但不是AbstractCollection.EMPTY, String.EMPTY
    • Array.length 但是List.size()
    • List.add(), Set.add()但是Map.put(), ByteBuffer.put()别忘了StringBuilder.append(), Stack.push()
        6
  •  8
  •   Freiheit    15 年前

    apachestringutils也解决了这个问题。

    其他选项的缺点:

    • 字符串为空,抛出一个NPE
    • length()==0-同样不是空安全的。 空白字符串。
    • 与空常量的比较-May

    被授予的StringUtils是另一个可以拖拽的库,但是它工作得非常好,并且节省了大量的时间和检查空值或优雅地处理NPE的麻烦。

        7
  •  4
  •   Donal Fellows    15 年前

    所有这些 "" 文字是同一个对象。为什么要这么复杂?只是打字时间长,而且不太清晰(编译器的成本很低)。因为Java的字符串是不可变的对象,所以根本不需要对它们进行区分,除非可能是为了提高效率,但是对于空字符串文本来说,这并不是什么大问题。

    如果你真的想 EmptyString 不变,自己做。但它所能做的只是鼓励编写更冗长的代码;会有的 从未 这样做有什么好处。

        8
  •  4
  •   Donal Fellows    15 年前

    为了补充Noel M所说的,你可以看看这个问题,这个答案表明常量被重用了。

    http://forums.java.net/jive/message.jspa?messageID=17122

    因此,实际上没有必要这样做 不变。

    String s=""; String t=""; boolean b=s==t; // true
    
        9
  •  3
  •   Nikita Rybak    15 年前

    我知道每次我键入字符串文本“”时,字符串池中引用的都是同一个字符串对象。
    没有这样的保证。在应用程序中不能依赖它,完全由jvm来决定。

    还是语言创造者根本不同意我的观点?

        10
  •  2
  •   Laurentiu Cristofor    5 年前

    回答晚了,但我认为这给这个话题增添了新的内容。

    以前的答案都没有回答原来的问题。有些人试图证明缺少常数是合理的,而另一些人则展示了我们可以处理缺少常数的方法。但是,没有人为常数的好处提供令人信服的理由,因此它的不足仍然没有得到适当的解释。

    常量很有用,因为它可以防止某些代码错误被忽略。

    OTOH是一个名为EMPTY的库常量,如果遇到同样的错误,它将为EMPTY之类的对象生成一个编译器错误。

    定义自己的常量更好。有人仍然可以错误地更改它的初始化,但是由于它的广泛使用,这种错误的影响比单个用例中的错误更难被忽视。

    这是使用常量而不是文字值的一般好处之一。人们通常认识到,对一个在许多地方使用的值使用一个常量可以让您在一个地方轻松地更新该值。不太常被承认的是,这也可以防止该值被意外修改,因为这样的更改会到处显示。所以,是的,“”比空的短,但是空的比“”更安全。

        11
  •  0
  •   howserss    4 年前

    有趣的是,它有多老了,现在还没有像C#那样的好的字符串类。 我做Java已经有几年了,现在我还做c#。当我使用Java时,我错过了c语言对于字符串的完整性。 主要是我想念string.Empty 以及string.IsNullOrEmpty(字符串)。 我也很怀念小写字符串类型。

    2020年及以后的快乐编码!!

        12
  •  0
  •   djangofan    4 年前

    似乎这是显而易见的答案:

    String empty = org.apache.commons.lang.StringUtils.EMPTY;
    

        13
  •  -18
  •   Mark Ursino    13 年前

    对于那些声称 "" String.Empty 是否可以互换 好点了,你大错特错了。

    每次你做类似myVariable=“”的事情时;您正在创建对象的实例。 如果Java的String对象有一个空的公共常量,则该对象只有一个实例“”

    例如:-

    String.EMPTY = ""; //Simply demonstrating. I realize this is invalid syntax
    
    myVar0 = String.EMPTY;
    myVar1 = String.EMPTY;
    myVar2 = String.EMPTY;
    myVar3 = String.EMPTY;
    myVar4 = String.EMPTY;
    myVar5 = String.EMPTY;
    myVar6 = String.EMPTY;
    myVar7 = String.EMPTY;
    myVar8 = String.EMPTY;
    myVar9 = String.EMPTY;
    

    10(11包括String.EMPTY)指向1个对象的指针

    或:-

    myVar0 = "";
    myVar1 = "";
    myVar2 = "";
    myVar3 = "";
    myVar4 = "";
    myVar5 = "";
    myVar6 = "";
    myVar7 = "";
    myVar8 = "";
    myVar9 = "";
    

    10个指针指向10个对象

    这是低效的,而且在整个大型应用程序中,这可能非常重要。

    也许Java编译器或运行时足够有效,可以自动将“”的所有实例指向同一个实例,但可能不是这样,而且需要额外的处理才能确定。