318

I understand that every time I type the string literal "", the same String object is referenced in the string pool.

But why doesn't the String API include a public static final String Empty = "";, so I could use references to String.Empty?

It would save on compile time, at the very least, since the compiler would know to reference the existing String, and not have to check if it had already been created for reuse, right? And personally I think a proliferation of string literals, especially tiny ones, in many cases is a "code smell".

So was there a Grand Design Reason behind no String.Empty, or did the language creators simply not share my views?

MC Emperor
  • 22,334
  • 15
  • 80
  • 130
Tom Tresansky
  • 19,364
  • 17
  • 93
  • 129
  • perhaps I'm missing something but why would you need it when you have String.length? – Aidanc Aug 10 '10 at 15:28
  • 6
    Aidanc: I think he means situations where you do stuff like `outputBlah = ""`, and he probably prefers `something == String.Empty` over `something.Length > 0` as well (you skip a null check.) – Skurmedel Aug 10 '10 at 15:31
  • 5
    @Aidanc - He was looking for an "empty member" like [Collections.EMPTY_SET](http://download.oracle.com/javase/1.5.0/docs/api/java/util/Collections.html#EMPTY_SET), not a function to check for string "emptiness". – Tim Stone Aug 10 '10 at 15:31
  • 3
    @Aidanc: What inspired this is actually 'TextBox.setText("");'. – Tom Tresansky Aug 10 '10 at 15:34
  • 3
    There's a `String.isEmpty()` function...why would you want `String.EMPTY`? – Buhake Sindi Aug 10 '10 at 15:42
  • 14
    `String.isEmpty()` does not return an empty string. – Steve Kuo Aug 10 '10 at 18:57
  • 1
    "It would save on compile time..." - if at all, then only a microsecond here or there... not enough to make a noticeable difference even with a massive code base. – Steve McLeod Aug 10 '10 at 22:02
  • There is some level of "Why have two different ways to do the same thing?" I mean, it's not like Java explicitly avoids that as a design principle, but it is a pretty good guideline. – Bill K Aug 27 '10 at 21:45
  • 5
    It may have little or no advantage in the actual code, but from a readability standpoint, it has value. (As a c# dev transitioning to java, I miss it) As someone else stated, `""` has the potential for error, because it isn't clear if empty was intended or the code is incomplete. Also, it's easy to miss the difference between `""` `" "` and `''` when reading the code. I think it has value from the point of avoiding string literals in code, and explicitly stating that it was intentional to set the variable as empty. – SouthShoreAK Feb 07 '13 at 21:46
  • 1
    I normally just use "". However, in a project I've worked on involving an internationalized application, the IDE threw an error if you used literal strings, and you had to add a //NON-NLS comment on that line to get rid of the error. For empty strings, this was unsightly as the comment was longer than the string. I mean, come on, an empty string is a empty string in any language, isn't it? – Klitos Kyriacou Feb 26 '15 at 16:29
  • 1
    If the same object is referenced every time you declare a variable with `""`, is that the same for all strings? Do `var1 = "this"; var2 = "this";` point to the same place? – AdamMc331 Jun 17 '15 at 15:03
  • Nitpicking: if there were such a constant, it should be `public static final String EMPTY = "";`. – MC Emperor Oct 21 '19 at 11:42

12 Answers12

215

String.EMPTY is 12 characters, and "" is two, and they would both be referencing exactly the same instance in memory at runtime. I'm not entirely sure why String.EMPTY would save on compile time, in fact I think it would be the latter.

Especially considering Strings are immutable, it's not like you can first get an empty String, and perform some operations on it - best to use a StringBuilder (or StringBuffer if you want to be thread-safe) and turn that into a String.

Update
From your comment to the question:

What inspired this is actually TextBox.setText("");

I believe it would be totally legitimate to provide a constant in your appropriate class:

private static final String EMPTY_STRING = "";

And then reference it as in your code as

TextBox.setText(EMPTY_STRING);

As this way at least you are explicit that you want an empty String, rather than you forgot to fill in the String in your IDE or something similar.

Noel M
  • 15,812
  • 8
  • 39
  • 47
  • 21
    I'll still +1 you, but I feel dirty because you mentioned `StringBuilder` without talking about how nine times out of ten it's totally inappropriate to use `StringBuilder` rather than concatenation. – Randolpho Aug 10 '10 at 15:36
  • 110
    I tend to prefer string.empty, mostly because it is more explicit. Also, there are rate situations where it can be harder to visually differentiate "" and things like "'". In the end as others have noted it is just one of those meaningless style things that give us fodder to argue over when we are bored with real work. =) – JohnFx Aug 10 '10 at 15:42
  • @Nodel M: Regarding compile time, I'd assume that if there are 2 string literals defined in 2 different source files with the same string value, when the compiler hits the 2nd one it needs to do some kind of check to figure out "hey, I already know about this string from back over here". I'm admittedly no expert in the java compiler, but how could this NOT be the case? And I would think skipping that check would result in a minuscule improvement in compile times. – Tom Tresansky Aug 10 '10 at 15:52
  • @Tom - I believe String interning is done at runtime, not compile time, so actually if you have the empty string as a constant in another file, the compiler needs to reference that class to resolve to the String literal. – Noel M Aug 10 '10 at 16:00
  • @Noel M: The JLS http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#101083 see section 3.10.5, seems inconclusive to my novice reading. This site: http://mindprod.com/jgloss/interned.html seems to suggest it is a compile time operation. – Tom Tresansky Aug 10 '10 at 16:18
  • @Tom - I've asked the question here- http://stackoverflow.com/questions/3451145/when-are-java-strings-interned , as it seems like we're straying a little off topic from this question – Noel M Aug 10 '10 at 16:32
  • 1
    @Randolpho When using string concatenation your are actually using a StringBuilder under the hood. – whiskeysierra Aug 10 '10 at 19:23
  • @Tom, compilers generally keep a hashed string table, so the lookup is O(1), so the overhead is negligible. – user207421 Aug 11 '10 at 01:58
  • 1
    -1 - String.EMPTY must be a final static reference, so that in running time it will be just a unique reference. If you use "" you are duplicating a reference everytime you use it. I think this is the background of the original question... – caligari Jun 19 '13 at 07:24
  • My example makes String.EMPTY a final static reference. And if you use "", they are all compiled to single reference in the intern pool. – Noel M Jun 19 '13 at 09:44
  • @whiskeysierra citation please? Because the fact that String is immutable suggests pretty strongly to me that concatenation most definitely isn't a simple equivalent of using StringBuilder. Also, Bloch seems to disagree as well; see Effective Java, Item 51. – Bane Nov 06 '13 at 00:12
  • 1
    I'm with @hfrmobile - I haven't tested this, but with regards to this being more efficient due to the number of characters, I disagree. _String.Empty_ is a static variable shared across all instances, will _""_ always instantiates a new empty string every time. String.Empty would be more efficient. – Aaron Newton Jun 20 '14 at 01:34
  • @AaronNewton The constant `""` will not create a new instance each time. It will be "compiled" into the constant pool of the class and at runtime will be interned. There will be a single constant `""` in the entire jvm. – Brett Okken Oct 17 '14 at 01:38
  • @Bane Look at the generated byte code of concatenation. It turns into creating a `StringBuilder` and appending to it. Using simple concatenation is easier to read and generally performs the same as explicitly using a `StringBuilder`. The one case where using a `StringBuilder` directly makes quite bit of sense is when the specifying the initial size. – Brett Okken Oct 17 '14 at 01:42
  • @Brett Are you certain about that? By which I mean, have you actually tested concatenation vs using StringBuilder? Because, unless something has fundamentally changed with the String API since about 2009, I can assure you that the performance of concatenation performs no where near the same as using SB; the latter is orders of magnitude faster. – Bane Oct 18 '14 at 03:46
  • I know this because a particular task I had was to iterate over a result set with several ten thousand entries and combine them into a single output string. I was surprised at how slow concatenation was, and relieved to find that doing it with SB was vastly better. – Bane Oct 18 '14 at 03:47
  • This code `return "SimpleMarkAsIdleResult [status=" + status + ", message=" + message + "]";` Turns into this byte code ` public j.l.String toString(); 0 new j.l.StringBuilder [33] 3 dup 4 ldc [35] 6 invokespecial j.l.StringBuilder(j.l.String) [37] 9 aload_0 [this] 10 getfield com.x.x.SimpleMarkAsIdleResult.status : com.x.x.MarkAsIdleResult.Status [26] 13 invokevirtual j.l.StringBuilder.append(j.l.Object) : java.lang.StringBuilder [39] 16 ldc – Brett Okken Oct 20 '14 at 21:33
  • @Bane I am certain about the byte code generated by oracle's jdk 1.5 and newer. The only case where explicit use of a `StringBuilder` will be faster, and that is for longer resulting strings where you size the `StringBuilder` appropriately when you create it. – Brett Okken Nov 12 '14 at 14:01
  • @BrettOkken I'm not sure if we're just talking past each other or what... but take a look at this [java-fiddle](http://shar.es/10LN5N) I made -- as you can see, SB is infinitely faster than String. In fact, doing 10K-concatenations, "StringBuilder was 2165ms faster than String". And that's a very small sample compared to what I had to do in ~2008, but it makes the point pretty clearly. Also, I reiterate: consider what Bloch says about this subject (ie: read Item 51, "Beware the performance of string concatenation"). What am I perhaps misunderstanding? – Bane Nov 13 '14 at 17:20
  • @BrettOkken Let me add that I ran that same code in my IDE running JDK1.7, with similar results. – Bane Nov 13 '14 at 17:40
  • @BrettOkken This dzone article just came out today and Item #1 is pretty relevant to this topic: ["Use StringBuilder"](http://java.dzone.com/articles/top-10-easy-performance) – Bane Feb 06 '15 at 20:12
  • @Bane, The use case of concatenating in a loop is somewhat different than what was being discussed. As pointed out in the dzone article, simple string concatenation is syntactic sugar for use of a `StringBuilder`. As it also goes on, more complex uses (such as additional concats or concats in a loop) results in creating additional `StringBuilder` instances, rather than continuing to work with a single instance. – Brett Okken Feb 07 '15 at 02:57
  • @NoelM: Start of this post you negate the need of such constant and at the end you are answering your own question about why we should have a constant. Secondly "" are hard to spot sometimes as well. anyway the real answer is `org.apache.commons.lang.StringUtils.EMPTY` as answered by jade – Mubashar Dec 28 '17 at 05:23
  • Isn't passing "" everytime creates a new garbage, where using a singleton in constant case creates this only once? – Mohammed Noureldin Jun 24 '18 at 23:44
  • You can use `StringUtils.EMPTY` **StringUtils** of Apache commons – Wael Ouni Sep 16 '19 at 16:02
  • "" will trigger garbage collection, since every time you use it it creates a new instance. In addition it's a good practice to use constants. – Mehdi Jan 06 '20 at 21:20
  • 1
    And don't forget that for "" we have to add //$NON-NLS-1$ which is 13 characters + 2 from "". So String.EMPTY would win both on length and aesthetics. – Yaza Apr 20 '20 at 17:25
  • @Mehdi If it's a local variable it almost certainly doesn't matter. The reference will not survive to the old generation in memory, and young generation GC is very cheap. You don't want to be creating references in a long running loop, but otherwise don't worry about it. – nasch Aug 27 '22 at 12:45
  • Do you use one letter variable names because they're shorter? Things should be named in a way that makes them as readable as possible, not as short as possible. – nasch Aug 27 '22 at 12:46
203

Use org.apache.commons.lang.StringUtils.EMPTY

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
jade
  • 2,059
  • 1
  • 11
  • 2
  • 50
    Looks a lot nicer and easier to read than an empty "". I hope it not just me. – Lakatos Gyula Jan 26 '15 at 21:09
  • 4
    @LakatosGyula - I think it might be (just you). Proficient Java programmers have no problems reading `""` ... and *most* would probably object loudly about use of `EMPTY` except in specific situations where `EMPTY` has a domain specific meaning. (And in such cases, there is probably a more appropriate name.) – Stephen C Feb 10 '15 at 22:59
  • 18
    @LakatosGyula It's not just you. I went from Java to .NET development, and String.Empty was a feature I was pleased to find in the framework. I like the explicit nature of it over an empty set of quotes. – yohohoho Feb 27 '15 at 04:07
  • 79
    @StephenC When I see an empty "" the first thing jumps in my mind that it's a bug, someone not finished the function etc. With String.EMPTY I know exactly that the developer intended to return an empty string. – Lakatos Gyula Mar 03 '15 at 18:32
  • 6
    Also helpful for all those times when the linter says "use a named constant instead of blah blah blah". Every programmer knows "" is not magic, but not having to explain it to the customer is better. – LizH Jun 22 '16 at 12:46
  • Only if you already have a dependency on that package. It's certainly not worth adding a package dependency just to avoid writing "" – kevin cline Jun 20 '19 at 01:07
  • This is the most correct answer to the original question asked. – claywhipkey Apr 09 '20 at 20:38
  • @claywhipkey This doesn't answer the question at all, but answers a different but closely related question. – nasch Aug 27 '22 at 12:38
33

If you want to compare with empty string without worrying about null values you can do the following.

if ("".equals(text))

Ultimately you should do what what you believe is clearest. Most programmers assume "" means empty string, not a string someone forgot to put anything into.

If you think there is a performance advantage, you should test it. If you don't think its worth testing for yourself, its a good indication it really isn't worth it.

It sounds like to you try to solve a problem which was solved when the language was designed more than 15 years ago.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • 1
    I am quite late to the party but, since Java strings are immutable, I believe that all empty strings within a JVM are just different references to the same String object. So simply the following is also correct: `if ("" == text)` – Ajoy Bhatia Apr 04 '12 at 22:14
  • 13
    @AjoyBhatia The problem is that you can create new empty strings. `if ("" == new String())` is false. A better test `if(text.isEmpty())` – Peter Lawrey Apr 05 '12 at 05:52
  • 1
    @AjoyBhatia - Only if the strings are interned. http://stackoverflow.com/questions/10578984/what-is-string-interning – Davor Sep 04 '14 at 11:57
14

Don't just say "memory pool of strings is reused in the literal form, case closed". What compilers do under the hood is not the point here. The question is reasonable, specially given the number of up-votes it received.

It's about the symmetry, without it APIs are harder to use for humans. Early Java SDKs notoriously ignored the rule and now it's kind of too late. Here are a few examples on top of my head, feel free to chip in your "favorite" example:

  • BigDecimal.ZERO, but no AbstractCollection.EMPTY, String.EMPTY
  • Array.length but List.size()
  • List.add(), Set.add() but Map.put(), ByteBuffer.put() and let's not forget StringBuilder.append(), Stack.push()
Slawomir
  • 3,194
  • 1
  • 30
  • 36
  • Even if you named the List parameter length() you still need the parenthesis since it's a method. Array.length is a public final variable, which only works because Arrays are immutable. So you'd still have Array.length and List.length(). I would argue that is more confusing and prone to error. As for .append() and .push(), while they do perform similar tasks I think they appropriately named. Appending the String is exactly what you're doing, but you don't "append" a Stack, you push and pop values. And StringBuilder.push() would imply StringBuilder.pop(), which isn't possible. – Craig Parton Jan 23 '19 at 10:25
  • Coming from templates/generics, consistent interfaces help with algorithms too. If an algorithm needs a length of a collection, length(T) or T.length() is all we care for. Similarly, adding to the end of a stack, list or a string could be done by a universal add() or append(). You mentioned that the array in Java is immutable/builtin type with an exposed length property. That's fine, it doesn't mean the compiler cannot handle or generate code for length(T) or T.length(). Kotlin generates a number of intrinsic methods for various cases. – Slawomir Jan 23 '19 at 19:35
  • But a consistently named length() method only lets us check length. How useful is that? If your goal is to abstract Lists and Arrays to make either usable in some way via an interface, you also need a consistent way to read or write data. So now you need to generate get(), set(), and add() methods. Essentially, you are creating a less functional List view of the Array. Since Arrays.asList() is available, easy to use, and lightweight, why reinvent the wheel? Arrays, Lists, StringBuilders, and Stacks all have a specific purpose. Seems better to design your interface to use the best fit. – Craig Parton Jan 23 '19 at 21:29
10

Seems like this is the obvious answer:

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

Awesome because "empty initialization" code no longer has a "magic string" and uses a constant.

djangofan
  • 28,471
  • 61
  • 196
  • 289
9

Apache StringUtils addresses this problem too.

Failings of the other options:

  • isEmpty() - not null safe. If the string is null, throws an NPE
  • length() == 0 - again not null safe. Also does not take into account whitespace strings.
  • Comparison to EMPTY constant - May not be null safe. Whitespace problem

Granted StringUtils is another library to drag around, but it works very well and saves loads of time and hassle checking for nulls or gracefully handling NPEs.

Freiheit
  • 8,408
  • 6
  • 59
  • 101
8

If you really want a String.EMPTY constant, you can create an utility static final class named "Constants" (for example) in your project. This class will maintain your constants, including the empty String...

In the same idea, you can create ZERO, ONE int constants... that don't exist in the Integer class, but like I commented, it would be a pain to write and to read :

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

Etc.

Benoit Courtine
  • 7,014
  • 31
  • 42
5

All those "" literals are the same object. Why make all that extra complexity? It's just longer to type and less clear (the cost to the compiler is minimal). Since Java's strings are immutable objects, there's never any need at all to distinguish between them except possibly as an efficiency thing, but with the empty string literal that's not a big deal.

If you really want an EmptyString constant, make it yourself. But all it will do is encourage even more verbose code; there will never be any benefit to doing so.

Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
  • 33
    `x = String.Empty` conveys intent better than `x = ""`. The latter could be an accidental omission. To say that there is *never* any benefit is incorrect. – Jeffrey L Whitledge Aug 10 '10 at 15:39
  • @Jeffrey: I don't think I particularly agree. It's one of these things where there's no hard and fast rule I suppose. – Donal Fellows Aug 10 '10 at 15:45
  • Yes, it's important to point out that the java compiler checks whether string literals already exist before creating a new instance in the string pool. – rds Nov 01 '13 at 10:09
  • 1
    @Jeffrey - knowing that this is a very old and subjective discussion. `x = String.Empty` conveys intent, true. But suppose the language provides a constant `String.Empty`, when you encounter `x = ""` you still know exactly as much about the intent as if there wasn't such a constant. You would need guarantee that all places in the worlds Java code where an empty string was intendet don't use `""` in order to get the information gain you mention. Ironically, C# does use a constant and encourages its use, so as I said, I know it is a very opinonated discussion. – chiccodoro Aug 13 '14 at 07:22
  • @chiccodoro - Yes, that’s true. That’s why the empty string literal `""` should be illegal, to rule out accidents. I’m kidding! – Jeffrey L Whitledge Aug 13 '14 at 15:40
4

To add on to what Noel M stated, you can look at this question, and this answer shows that the constant is reused.

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

String constant are always "interned" so there is not really a need for such constant.

String s=""; String t=""; boolean b=s==t; // true
Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
James Black
  • 41,583
  • 10
  • 86
  • 166
3

I understand that every time I type the String literal "", the same String object is referenced in the String pool.
There's no such guarantee made. And you can't rely on it in your application, it's completely up to jvm to decide.

or did the language creators simply not share my views?
Yep. To me, it seems very low priority thing.

Nikita Rybak
  • 67,365
  • 22
  • 157
  • 181
  • 6
    *There's no such guarantee made* ...Well, the JLS [does state](http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.5) that should be the case. – Tim Stone Aug 10 '10 at 15:46
  • @Tim Not unless you make 'intern' call. It's easy to construct two equal big strings programmatically and check. – Nikita Rybak Aug 10 '10 at 15:52
  • @Tim For example, repeat _a += "a";_ 100 times, do same with _b_ and check. – Nikita Rybak Aug 10 '10 at 15:54
  • 5
    You're right, but what you've described isn't a string literal, nor an expression whose result can be guaranteed at compile time (such as `String username = "Bob" + " " + "Smith";`). Strings created programmatically have no guarantees of being interned, unless you explicitly call `intern()` as you've stated. The OP's scenario describes using the blank string literal `""` throughout the code though, which is a case where automatic interning would occur. – Tim Stone Aug 10 '10 at 16:13
  • @Tim `String a = ""; for(int i = 0; i < 100; i++) {a += "a";} String b = ""; for(int i = 0; i < 100; i++) {b += "b";} a.intern(); b.intern();` Now the `a` and `b` point to the same memory location in PermGen. See [this article](http://java-performance.info/string-intern-in-java-6-7-8/) – 1ac0 Oct 07 '14 at 09:58
3

Late answer, but I think it adds something new to this topic.

None of the previous answers has answered the original question. Some have attempted to justify the lack of a constant, while others have showed ways in which we can deal with the lack of the constant. But no one has provided a compelling justification for the benefit of the constant, so its lack is still not properly explained.

A constant would be useful because it would prevent certain code errors from going unnoticed.

Say that you have a large code base with hundreds of references to "". Someone modifies one of these while scrolling through the code and changes it to " ". Such a change would have a high chance of going unnoticed into production, at which point it might cause some issue whose source will be tricky to detect.

OTOH, a library constant named EMPTY, if subject to the same error, would generate a compiler error for something like EM PTY.

Defining your own constant is still better. Someone could still alter its initialization by mistake, but because of its wide use, the impact of such an error would be much harder to go unnoticed than an error in a single use case.

This is one of the general benefits that you get from using constants instead of literal values. People usually recognize that using a constant for a value used in dozens of places allows you to easily update that value in just one place. What is less often acknowledged is that this also prevents that value from being accidentally modified, because such a change would show everywhere. So, yes, "" is shorter than EMPTY, but EMPTY is safer to use than "".

So, coming back to the original question, we can only speculate that the language designers were probably not aware of this benefit of providing constants for literal values that are frequently used. Hopefully, we'll one day see string constants added in Java.

Laurentiu Cristofor
  • 170
  • 7
-19

For those claiming "" and String.Empty are interchangeable or that "" is better, you are very wrong.

Each time you do something like myVariable = ""; you are creating an instance of an object. If Java's String object had an EMPTY public constant, there would only be 1 instance of the object ""

E.g: -

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 including String.EMPTY) Pointers to 1 object

Or: -

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

10 pointers to 10 objects

This is inefficient and throughout a large application, can be significant.

Perhaps the Java compiler or run-time is efficient enough to automatically point all instances of "" to the same instance, but it might not and takes additional processing to make that determination.

Mark Ursino
  • 31,209
  • 11
  • 51
  • 83
Antony Booth
  • 11
  • 1
  • 12
    Wrong, according to http://stackoverflow.com/questions/1881922/questions-about-javas-string-pool , the "" string will be reused from String pool. – RealHowTo Mar 02 '12 at 22:57
  • 1
    I stated it might reuse the same object and if so, is still less efficient, because it needs to find that object (in the string pool), so how am I wrong? Regardless, there are several reason why String.Empty is superior, including preventing errors such as myVar = " "; and readability as well as the performance improvement I already stated. It is good practice to use constants instead of creating string literals, if for no other reason; it is easier to maintain code. – Antony Booth Mar 06 '12 at 18:19
  • 1
    I doubt that your performance argument is valid because the JLS says that a constant will be treated as literal at compile time ( http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.10.5 ). The readability is a better argument. – RealHowTo Mar 06 '12 at 21:14
  • 4
    @AntonySmith - I guess you need to study Java a little more or perhaps you know your error by now. Java strings are immutable and in a pool. So there is only ONE String object for "" in a JVM, no matter how many times it is found in the code. You can check whether a string is empty by doing `if (text == "")` – Ajoy Bhatia Apr 04 '12 at 22:37
  • @AjoyBhatia Only literal strings can be compared that way, not one created using `new String()` – Ruan Mendes Oct 09 '12 at 23:14
  • @AjoyBhatia in context of reflections we can't speak of immutability if it's not marked as volatile – ceph3us Jul 31 '15 at 00:39
  • @TomaszBest - Sorry, I did not understand what you mean in your comment above. – Ajoy Bhatia Aug 02 '15 at 16:34
  • @AjoyBhatia Except for ROM there is no immutable memory in your computer. Nowadays even ROM is sometimes writable. There is always some code some where (wether it's the kernel or native code sidestepping your managed environment) that can write to your memory address. So, in "reality", no they are not absolutely immutable. BEST EXAPLE IS TO USE REFLECTIONS – ceph3us Aug 02 '15 at 16:50
  • 3
    Wrong. This comment should be deleted. – Elad Tabak Nov 09 '16 at 08:04