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.
Related
I am wondering if there is a ready made Java class that can be used similarly with Guava's Optional but treats null and absent differently.
I have use case that requires to pass a method parameter with String value, null value or absent (does not provide anything). Null is a purely valid value and carries special meaning.
I tried to use Guava's Optional but found that it cannot differentiate null and absent. Passwing null to Optional means absent.
I am wondering if there is a ready made Java utility that can be used for my usecase: It can carry a value, null value or no value (absent).
many thanks
The java language can do it: Use a token object to represent "absent".
Say it's a String type:
private static final String ABSENT = new String(""); // not interned
private String attribute = ABSENT;
public boolean attributeIsSet() {
return attribute == ABSENT; // identity comparison
}
public String getAttribute() {
if (attributeIsSet())
return attribute;
throw new IllegalStateException(); // or whatever
}
This allows null to be a valid value.
You should use Optional.
Optional is you know that something is either present or not. Add the meaning null to Optional by returning... null.
Optional<A> a = Optional.of(new A()); // We know that A is present.
Optional<B> b = Optional.absent(); // We know that B is absent.
Optional<C> c = null; // We don't know if C is present or absent.
Working with null isn't bad: it's error-prone. So be careful, document properly what you want to do and how null should be interpreted.
Null ... carries special meaning.
Whenever you find yourself saying this, it should be a red flag that your design merits re-thinking, as null by definition carries no meaning. Lets step back and look at your requirements (feel free to update the question with better descriptions of your intent if this is inaccurate):
Absence: Indicates we've nothing to do here at all
null: Indicates a "special value", such as DEFAULT or FALLBACK, which should be handled specially
Value: A "normal" value, including the empty string, that can be handled directly
This is not an unusual problem, (particularly when working with nullable database columns, as I think you are) and Optional can quite successfully represent this, but we need to structure it better.
While we can't avoid NULLs in databases, we can strive to restrict their scope to the minimal code surrounding our database access behavior, and expose it no further than that. We conceptually do this by converting nullable fields to Optionals, as you know. So col VARCHAR NULL should always be converted into Java as an Optional<String> col as soon as possible.
But now we need to represent the absence case, such as when we SELECT col FROM table LIMIT 1 and get nothing back from our query. Obviously, this should be handled differently than if we get back a NULL.
We have a couple of choices, but they all boil down to wrapping our Optional<String> in another layer somehow.
In many cases you can simply use a List or other Collection. By passing back a non-null collection we can generally handle the absent case trivially, as our code will simply not enter whatever loop would otherwise process the data if the List is empty. So List<Optional<String>> is one option.
If that's not possible, and you really want to limit the behavior to one-or-none, such as in the LIMIT 1 example above, simply wrap it in another Optional, i.e. Optional<Optional<String>>. This clearly conveys the difference between absence of a result, and absence of a value in a type-safe manner.
A little more work, but even better is to properly represent this structure in its own class (any time you have generics inside generics, consider creating a proper holding class), since really what we're talking about is a optional piece of data, which may itself contain an optional piece of data.
public class Row {
private final Optional<String> col;
public Row(#Nullable String col) {
this.col = Optional.fromNullable(col);
}
public Optional<String> getCol() {
return col;
}
}
Then you pass around Optional<Row> objects, which very clearly either exists or doesn't, and either contain a result, or not. All type-safe, and no nulls needed.
tl;dr: This can be rationally represented with Optional<Optional<String>>, or see above for additional suggestions.
Isn't an empty String ("") the same as 'no value' for a string? Obviously this wouldn't work for numbers, but you're specifically talking about a String.
What is the best way if I have many object references which NEED to be initiliazed (in a method) to a default value and I don't want to mess my code with many lines like:
String name = null;
String address = null;
String type = null;
String edition = null;
String year = null;
I sometimes use:
String name, address, type, edition, year;
name = address = type = edition = year = null;
Is there a better way? Is this way OK?
EDIT: These are instance variables. The purpose of this question is (as the tag indicates) to improve my code-style. I just want to produce the cleanest code and human readable as possible in when encountering this situation. What I am excepting as answer is some best-practices suggestions from experienced coders and I am not interested in explanation of how variable initialization of variables in java works as this is irrelevant for this question.
EDIT2: These variables need to be initialized. I am aware of basic rules of variables initialization in java.
Having multiple assignments in one statement is considered bad quality and discouraged by the Java Coding Conventions (Section 10.4). I haven't seen multiple assignments in one statement in any serious commercial software development, because of the lack of readability. I strongly suggest to use separate assignments.
Please see my answer to an almost identical question for more details.
Both ways act as same way after compile. But it is better to use first way since it is more readable and easy to understand. But you should use variables according to context.
Non-primitive Objects are by default null. So, this means that:
String name = null;
is equivalent with:
String name;
Note that this is only the case for class members. Local variables behave differently.
Not only is the first easier to understand, the second one will create extra work in the case you decide once to change the initial value of one of the variables. Then you have to restructure the entire code. That’s not recommended. Further, keep in mind that this only works in the case of null and immutable objects and since you should not switch between different code styles you should use a pattern that works with all kinds of initial values. In other words: initialize the variables individually. This also will help if you want to turn one or some of the variables into a compile-time constant.
As per Datatypes, there is no need for you to assign null to object instance variables, Fields that are declared but not initialized will be set to a reasonable default by the compiler, in your case it will be set to null by default.
String name, address, type, edition, year=null;
Why dont you do like this. This makes your code cleaner as expected.
The only declaration
String name, address, type, edition, year;
is enough.
Because in Java, String is a class and every String reference variable are initialized to null if none of the object is assigned to it.
String name, address, type, edition, year;
it means
String name = null;
String address = null;
String type = null;
String edition = null;
String year = null;
So no need to declare the objects like this and to initialize them explicitly to null.
I need to know the difference of initializing the String in java when using the runtime.
For Exmaple:
String declare = null;
otherwise:
String declare = "";
I declared the two type of declaration of string. Which one is best for runtime declaration.
A String is an object. If you initialize it to null, you are telling the compiler that you are aware that wasn't initialized, and that there should be no warnings when you first try to use the variable. Aside from that, you are pointing a reference to null, of course.
If you initialize the String to an empty String, however, the following happens:
There's now a String object allocated
The compiler will put that String literal in the String pool
Any other String that you initialize to "" will point to the same inmutable String from that pool
So, the question is, how do you handle nulls or empty Strings in your code? That's what should guide your decision
In first case you have created a 'pointer' to a null object (objec is not created). In second one - the 'pointer' to the object with value "" (empty string). These are qiute different things - you need to decide, which one do you need for further manipulations.
First example will not create a String object, and second will. So, the statement:
declare.equals("some string");
will generate a NullPointerException for your first example, but not for the second.
As #AljoshaBre commented, it depends on what you are going to do with it. Having it initialized to null is somewhat redundant, for the initial value usually is that. The blank initialization ("") makes it impossible to receive a null pointer exception if you go through an unexpected path (which may be good or bad, because it might mask logic errors in your code).
Having an initial value is usually good, but make it so that it is meaningful for the code that is going to use your String, not a random initial value.
I asked this goofy question earlier today and got good answers. I think what I really meant to ask is the following:
String aString = ""; // Or = null ?
if(someCondition)
aString = "something";
return aString;
In this case, the string has to be initialized in order to return it. I always thought that either option (setting it to "" or to null looks kind of ugly. I was just wondering what others do here...or is it more of just a matter of whether you want empty string or null being passed around in your program (and if you are prepared to handle either)?
Also assume that the intermediary logic is too long to cleanly use the conditional (? :) operator.
return (someCondition) ? "something" : "";
or
return (someCondition) ? "something" : null;
Typically though if your function says it will return a String I prefer to actually return a String instead of a null. Either way the calling function should probably check for both cases.
depends on what you want to achieve,
in general i would return null to signal that nothing was processed,
it might later pop up cases where someCondition is true but the string you build together is "" anyway, that way you can differentiate from that case if you return null if nothing was processed.
i.e.
String aString = null;
if(someCondition)
aString = "something";
return aString;
but it all really depends on what you want to achieve...
e.g. if the code is suppose to build together a string that is delivered directly in the UI you would go for "" instead
In this case it might be best to do something like:
public void func() {
boolean condition = getConditionFromSomewhere();
String condString = getAppropriateValue(condition);
}
public String getAppropriateValue(boolean condition) {
if (condition) {
return "something";
} else {
return "somethingElse";
}
}
It may seem a bit overkill for a boolean condition, but if you get into more complex conditions (more choices, like enums and the like), it would nicely abstract that logic away. And with a descriptive method name make it almost self-documenting to boot.
Since you're asking our opinions...
I'm a bit overconscious about quality. I prefer that all my "if" statements have an "else", because (1) it helps to understand the code if there are multiple nested "if's", (2) force me to consider the possibility (what should happen if the condition is false?).
Regarding reason (1), I prefer to avoid nested if's, but sometimes you inherit code with a lot of if's.
if(someCondition)
aString = "something";
else
aString = "";
I would prefer "null", because it would make the app fail and dump a stack that I can follow. An empty string, in contrast, would keep things going. Naturally, it depends on the logic of your code what is better: null or "".
Yes, this is just a matter of whether you want a null or an empty string being passed around in your program. If you plan to append things to it later, and the someCondition just indicates that you should give it a first value to begin with, then use the empty string. If you plan to have it indicate that there is a string or there is nothing, then perhaps using null is better.
Its just your preference of what your api should do. If you are returning null, there may be a chance that the api users can get NPE if they are not checking for null. But if you are using "" string, the error may pass silently if it is not supposed to be null. It is a preference of how you write your api and depends on the use case.
Thinking about it, I rarely use "" in code for any purpose.
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)