We Keep Coding

How immutable String value is getting changed without throwing compilation error.

I am reassigning value of a String variable. How this vaule is reassigned wihout thorwing error as String is immutable.

If you mean, you're doing this:
String s = "one";
s = "two";
...and wondering why it works, it's because the string is immutable, but the variable is not. You can update the variable to point to a different string. You can't change the string it points to so that it has different characters in it.¹
¹ (Well, actually, you can with reflection with some JDK implementations by finding the underlying character array and changing it. But officially, in theory, you can't.)

What is difference between using "pure" String and String returned from method?

I'm new to programming and as I was using some strings in Java I could not figure out this probably simple question:
If we have method:
public static String str(String arg)
{
return arg;
}
Is there any difference between those two samples below?
System.out.println("Hello");
vs
System.out.println(Someclass.str("Hello"));
What is processed faster? Is it better to set arguments of methods using return value of different method or using chosen datatype directly? Is there any practical use of second sample?
Thanks and sorry if it's dumb question.

There is no difference, except that the second example is more obfuscatory, the method call doesn't add any value. Run this code:
"Hello".equals(Someclass.str("Hello"));
It will return true, that tells you that the strings are equivalent.
All the method in the second example does is take the reference passed in and return it, so the code
String s = "Hello";
System.out.println(Someclass.str(s) == s);
will print true; s and Someclass.str's return value should be the same reference.
Don't fixate on performance, try to write code that makes sense.

The first case is slightly faster and it makes no sense using the second one unless you are modifying the string in Someclass's str method.

In Java, all parameters are passed by value. This includes references to objects like Strings. When you call the str(String arg) method, you are not actually passing the String into the method, rather a copy of the reference that points to the String's location in memory. When you return arg, again, you are returning a copy of this reference to the String.
In your second example you are using a String literal. Java treats these in a special way (the compiler essentially creates a constant and substitutes that constant in place of the literal wherever you see it in code). So when you pass the literal in, you are actually passing a copy of the reference (memory location) of the literal, and then returning it. There is still only one String object.
In other words, all you are doing is adding a small amount of overhead by inserting the method call in the middle.

The first case is faster.
The second case is nonsensical. You are passing a String to a method which simply returns that same String object. There is absolutely no reason to do this. It will probably be a bit slower because of the unnecessary method call.
Using double quotes will already automatically create a String object.
And in any case, readable code far outweighs small performance boosts in all but the most demanding scenarios.

Time of Strings Creation in Java

I am writing an app for J2ME devices and pretty much care about unnecessary String creation.
As working with Strings is built-in, i.e. it is not necessary to create them explicitly, I am not sure if I understand it right.
For instance returning a String (just by using the double quotes) creates the string when it is being returned, i.e. if I have several return statements returning different Strings, only one of the would be created. Is that right?
Also when using Strings for printing messages with Exceptions, these Strings never get created, if the Exception doesn't get thrown, right?
Sorry to bother you with such a newbie question.

I'm not at all sure about the answers you've received so far. If you're just returning a string literal, e.g.
return "foo";
then those values are embedded into the class file. The JVM makes sure that only one instance of that string is ever created (from the literal) - but I don't think there's any guarantee that it won't create strings for all the constants in a class when the class itself is loaded.
Then again, because the string will only be created once (per string constant) it's unlikely to be an issue.
Now, if your code is actually more like this:
return "foo" + new Date();
then that is dynamically creating a string - but it will only be created if the return statement is actually hit.

The answer is a bit more complicated than some of the other answers suggest.
The String value that corresponds to a String literal in your source code gets created once, when the class is loaded. Furthermore, these Strings are automatically "interned", which means that if the same literal appears at more than one place in any class, only one copy of the String will be kept. (Any other copies, if they were created will get garbage collected.)
When the application calls new String(...), when it evaluates a String concatenation expression (i.e. the + operator), or when it calls one of the many library methods that create Strings under the hood, a new String will be created.
So to answer your questions:
1 - The following will not actually create a String at all. Rather it will return a String that was created when the class was loaded:
return "some string";
2 - The following will create two Strings. First it will call someObject.toString(), then it will concatenate that with the literal to give another String.
return "The answer is :" + someObject;
3 - The following will not create a String; see 1.
throw new Exception("Some message");
4 - The following will create two Strings when it is executed; see 2.
throw new Exception(someObject + "is wrong");
(Actually, 3 and 4 gloss over the fact that creating an exception causes details of the current thread's call stack to be captured, and those details include a method name, class name and file name for each frame. It is not specified when the Strings that represent these things actually get created, or whether they are interned. So it is possible that the act of creating an Exception object triggers creation of a number of Strings.)

Right
Right

Yes. If an expression that creates an instance either by invoking a constructor or if (for Strings) evaluating a literal is not executed, then nothing is created.
And furtheron, compilers do some optimization. String objects based on String literals will be created only once and interned afterwards. like here:
public String getHello() {
return "Hello";
}
public void test() {
String s = getHello(); // String object created
String t = getHello(); // no new String object created
}
The JVMS has a different 'opinion':
A new class instance may be implicitly created in the following situations:
Loading of a class or interface that contains a String literal may create a new String object (§2.4.8) to represent that literal. This may not occur if the a String object has already been created to represent a previous occurrence of that literal, or if the String.intern method has been invoked on a String object representing the same string as the literal.
So the above example is incorrect (I'm learning something new every day). The VM checks during classloading if "Hello" has to be created or not (and will create a String instance if not existing yet).
So now it is my understanding, that the VM creates a String instance for each unique String literal (on byte code level!), regardless whether it is used or not.
(on byte code level because compilers may optimize concatenations of String literals to one literal, like: the expression "one"+"two" will be compiled to "onetwo")

Strings (and other objects) only get created when you call them.
So to answer your questions:
Yes, only the String that gets returned will get created
Yes, only when the exception is thrown, this String will get created

The main concept here is that the heap allocation(what you say creation) for any String or in more general terms for any object doesn't take place until your logic-flow makes the interpreter executes that line of compiled code.

Should I set the initial java String values from null to ""?

Often I have a class as such:
public class Foo
{
private String field1;
private String field2;
// etc etc etc
}
This makes the initial values of field1 and field2 equal to null. Would it be better to have all my String class fields as follows?
public class Foo
{
private String field1 = "";
private String field2 = "";
// etc etc etc
}
Then, if I'm consistent with class definition I'd avoid a lot of null pointer problems. What are the problems with this approach?

That way lies madness (usually). If you're running into a lot of null pointer problems, that's because you're trying to use them before actually populating them. Those null pointer problems are loud obnoxious warning sirens telling you where that use is, allowing you to then go in and fix the problem. If you just initially set them to empty, then you'll be risking using them instead of what you were actually expecting there.

Absolutely not. An empty string and a null string are entirely different things and you should not confuse them.
To explain further:
"null" means "I haven't initialized
this variable, or it has no value"
"empty string" means "I know what the value is, it's empty".
As Yuliy already mentioned, if you're seeing a lot of null pointer exceptions, it's because you are expecting things to have values when they don't, or you're being sloppy about initializing things before you use them. In either case, you should take the time to program properly - make sure things that should have values have those values, and make sure that if you're accessing the values of things that might not have value, that you take that into account.

Does it actually make sense in a specific case for the value to be used before it is set somewhere else, and to behave as an empty String in that case? i.e. is an empty string actually a correct default value, and does it make sense to have a default value at all?
If the answer is yes, setting it to "" in the declaration is the right thing to do. If not, it's a recipe for making bugs harder to find and diagnose.

I disagree with the other posters. Using the empty string is acceptable. I prefer to use it whenever possible.
In the great majority of cases, a null String and an empty String represent the exact same thing - unknown data. Whether you represent that with a null or an empty String is a matter of choice.

Generally it would be best to avoid this. A couple of reasons:
Getting a NullPointerException is generally a good warning that you are using a variable before you should be, or that you forgot to set it. Setting it to an empty string would get rid of the NullPointerException, but would likely cause a different (and harder to track down) bug further down the line in your program.
There can be a valid difference between null and "". A null value usually indicates that no value was set or the value is unknown. An empty string indicates that it was deliberately set to be empty. Depending on your program, that subtle difference could be important.

I know this is an old question but I wanted to point out the following:
String s = null;
s += "hello";
System.out.println(s);// this will return nullhello
whereas
String s = "";
s += "hello";
System.out.println(s); // this will return hello
obviously the really answer to this is that one should use StringBuffer rather than just concatenate strings but as we all know that for some code it is just simpler to concatenate.

I would suggest neither.
Instead you should give your fields sensible values. If they don't have to change, I would make them final.
public class Foo {
private final String field1;
private final String field2;
public Foo(String field1, String field2) {
this.field1 = field1;
this.field2 = field2;
}
// etc.
}
No need to assign, i'm-not-initialised-yet values. Just give it the initial values.

I would avoid doing this, you need to know if your instances aren't getting populated with data correctly.

Null is better, that is why they are called unchecked exceptions {Null pointer exception}. When the exception is thrown, it tells you that you have to initialize it to some non null value before calling any methods on it.
If you do
private String field1 = "";
You are trying to supress the error. It is hard to find the bug, later.

I think when you use String s = null it will create variable "s" on stack only and no object will exists on heap,but as soon as you declare things as like String s=""; what it will does is like it will create "" object on heap.As we know that Strings are immutable so whenever u wil assign new value to string varible everytime it will create new Object on heap...So I think String s=null is efficient than String s = "";
Suggestions are welcome!!!!!

No way. Why do you want to do that? That will give incorrect results. nulls and """ are not same.

Is making an empty string constant worth it?

I have a co-worker that swears by
//in a singleton "Constants" class
public static final String EMPTY_STRING = "";
in a constants class available throughout the project. That way, we can write something like
if (Constants.EMPTY_STRING.equals(otherString)) {
...
}
instead of
if ("".equals(otherString)) {
...
}
I say it's
not worth it--it doesn't save any space in the heap/stack/string pool,
ugly
abuse of a constants class.
Who is the idiot here?

String literals are interned by default, so no matter how many times you refer to "" in code, there will only be one empty String object. I don't see any benefit in declaring EMPTY_STRING. Otherwise, you might as well declare ONE, TWO, THREE, FOUR, etc. for integer literals.
Of course, if you want to change the value of EMPTY_STRING later, it's handy to have it in one place ;)

Why on earth would you want a global variable in Java? James Gosling really tried to get rid of them; don't bring them back, please.
Either
0 == possiblyEmptyString.length()
or
possiblyEmptyString.isEmpty() // Java 6 only
are just as clear.

I much prefer seeing EMPTY_STRING.
It makes it english. "".equals 'reads' differently than EMPTY_STRING.equals.

Ironically the whole point of constants is to make them easily changeable. So unless your co-worker plans to redefine EMPTY_STRING to be something other than an empty string - which would be a really stupid thing to do - casting a genuine fixed construct such as "" to a constant is a bad thing.
As Dan Dyer says, its like defining the constant ONE to be 1: it is completely pointless and would be utterly confusing - potentially risky - if someone redefined it.

Well, I could guess too, but I did a quick test... Almost like cheating...
An arbitrary string is checked using various methods. (several iterations)
The results suggests that isEmpty() is both faster and indeed more readable;
If isEmpty() is not available, length() is a good alternative.
Using a constant is probably not worth it.
"".equals(someString()) :24735 ms
t != null && t.equals("") :23363 ms
t != null && t.equals(EMPTY) :22561 ms
EMPTY.equals(someString()) :22159 ms
t != null && t.length() == 0 :18388 ms
t != null && t.isEmpty() :18375 ms
someString().length() == 0 :18171 ms
In this scenario;
"IAmNotHardCoded".equals(someString())
I would suggest defining a constant in a r e l e v a n t place, since a global class
for all constants really sucks. If there is no relevant place, you are probably doing something else wrong...
Customer.FIELD_SHOE_SIZE //"SHOE_SIZE"
Might be considered a relevant place where as;
CommonConstants.I__AM__A__LAZY__PROGRAMMER // true
is not.
For BigIntegers and similar thing, I tend to end up defining a final static locally; like:
private final static BigDecimal ZERO = new BigDecimal(0);
private final static BigDecimal B100 = new BigDecimal("100.00");
Thats bugs me and wouldn't it be nice with some sugar for BigInts and BigDecimals...

I'm with your coworker. While the empty string is hard to mistype, you can accidentally put a space in there and it may be difficult to notice when scanning the code. More to the point it is a good practice to do this with all of your string constants that get used in more than one place -- although, I tend to do this at the class level rather than as global constants.
FWIW, C# has a static property string.Empty for just this purpose and I find that it improves the readability of the code immensely.

As a tangent to the question, I generally recommend using a utility function when what you're really checking for is "no useful value" rather than, specifically, the empty string. In general, I tend to use:
import org.apache.commons.lang.StringUtils;
// Check if a String is whitespace, empty ("") or null.
StringUtils.isBlank(mystr);
// Check if a String is empty ("") or null.
StringUtils.isEmpty(mystr);
The concept being that the above two:
Check the various other cases, including being null safe, and (more importantly)
Conveys what you are trying to test, rather than how to test it.

David Arno states: -
Ironically the whole point of
constants is to make them easily
changeable
This is simply not true. The whole point of constants is reuse of the same value and for greater readability.
It is very rare that constant values are changed (hence the name). It is more often that configuration values are changed, but persisted as data somewhere (like a config file or registry entry)
Since early programming, constants have been used to turn things like cryptic hex values such as 0xff6d8da412 into something humanly readable without ever intending to change the values.
const int MODE_READ = 0x000000FF;
const int MODE_EXECUTE = 0x00FF0000;
const int MODE_WRITE = 0x0000FF00;
const int MODE_READ_WRITE = 0x0000FFFF;

I don't like either choice. Why not if (otherString.length() == 0)
Edit: I actually always code
if (otherString == null || otherString.length() == 0)

yes--it offers no benefit.
depends on what you're used to, I'm sure.
No, it's just a constant--not an abuse.

The same argument comes up in .NET from time to time (where there's already a readonly static field string.Empty). It's a matter of taste - but personally I find "" less obtrusive.

Hehe, funny thing is:
Once it compiles, you wont see a difference (in the byte-code) between the "static final" thing and the string literal, as the Java-compiler always inlines "static final String" into the target class. Just change your empty string into something recognizable (like the LGPL-text) and look at the resulting *.class file of code that refernces that constant. You will find your text copied into that class-file.

One case where it does make sense to have a constant with value of empty string is when you the name captures the semantics of the value. For example:
if (Constants.FORM_FIELD_NOT_SET.equals(form.getField("foobar"))) {
...
}
This makes the code more self documenting (apart from the argument that a better design is to add the method checking whether a field is set to the form itself).

We just do the following for situations like this:
public class StaticUtils
{
public static boolean empty(CharSequence cs)
{
return cs == null || cs.length() == 0;
}
public static boolean has(CharSequence cs)
{
return !empty(cs);
}
}
Then just import static StaticUtils.*

Hmm, the rules are right but are being taken in a different sense! Lets look at the cause, firstly all object references in java are checked by equals(). Earlier on, in some languages it was done using '==' operator, if by accident someone used '=' for '==', a catastrophe. Now the question of magic numbers/constants, for a computer all constants/numbers are similar. Instead of 'int ONE=1' one can surely use 1, but will that hold true for double PI = 3.141...? What happens if someone tries to change the precision sometime later.
If we were to come up with a check list, what would the rule be address the general guideline isn't it? All I mean to say is that rules are supposed to aid, we can surely bend the rules only when we know them very well. Common sense prevails. As suggested by a friend of mine, program constants like 0/1 which denote exit conditions can be hard coded and hence magic number principle doesn't apply. But for those which participate in logical checks/rules, better keep them as configurable constants.

Why it is preferable to use String.Empty in C# and therefore a public constant in other languages, is that constants are static, therefore only take up one instance in memory.
Every time you do something like this: -
stringVariable = "";
you are creating a new instance of a null string, and pointing to it with stringVariable.
So every time you make an assignment of "" to a variable (pointer), that "" null string is a new string instance until it no longer has any pointer assignments to it.
initializing strings by pointing them all to the same constant, means only one "" is ever created and every initialized variable points to the same null string.
It may sound trivial, but creating and destroying strings is much more resource intensive than creating pointers (variables) and pointing them to an existing string.
As string initialization is common, it is good practice to do: -
const String EMPTY_STRING = "";
String variable1 = EMPTY_STRING;
String variable2 = EMPTY_STRING;
String variable3 = EMPTY_STRING;
String variable4 = EMPTY_STRING;
String variable5 = EMPTY_STRING;
You have created 5 string pointers but only 1 string
rather than: -
String variable1 = "";
String variable2 = "";
String variable3 = "";
String variable4 = "";
String variable5 = "";
You have created 5 string pointers and 5 separate null strings.
Not a major issue in this case, but in thousands of lines of code in dozens of classes, it is unnecessary memory waste and processor use, creating another null string variable, when they can all point to the same one, making applications much more efficient.
Of course, compilers should be clever enough to determine several static strings and reuse duplicates, but why assume?
Also, it's less prone to introducing errors as "" and " " will both compile, yet you may miss the space you accidentally added which could produce spurious run time errors, for example conditional logic such as: -
myvariable = " ";
While (myVariable == ""){
...
}
Code inside the while block is unreachable because myVariable will not satisfy the condition on the first iteration. The error of initializing with " " instead of "" is easy to miss, whereas: -
myvariable = EMPTY_STRING;
While (myVariable == EMPTY_STRING){
...
}
... is less likely to cause runtime errors, especially as misspelling EMPTY_STRING would generate a compile error instead of having to catch the error at run time.
The cleanest solution, would be to create a static class that contains members of all kinds of string constants you need, should you require more than just an empty string.
public static class StringConstants{
public static String Empty = "";
public static String EMail = "mailto:%s";
public static String http = "http://%s";
public static String https = "https://%s";
public static String LogEntry = "TimeStamp:%tYmdHMSL | LogLevel:%s| Type:%s | Message: '%s'";
}
String myVariable = StringConstants.Empty;
You may even be able to extend the native String object, depending on your language.

If you every wish to store "empty" strings in a nullable string column in oracle, you will have to change the definition of EMPTY_STRING to be something other than ""! (I recall from the last time I was forced to use Oracle that it does not know the difference between an empty string and a null string).
However this should be done in your data access layer so the rest of the app does not know about it, and/or sort out your data model so you don’t need to store empty string AND null strings in the same column.

Or simply just have it as string.IsNullOrEmpty(otherString)