I am trying to understand if it is useful to use String during programming, there is general notion in our group that using String is bad practice and enum is way to go but I am not able to find enough reasoning to give in my vote against String and would appreciate any thoughts and example on the issue?
Update:
I should re-phrase my question to word like under what situation usage of String is evil and what alternative dataType you should be using for the same.
String is useful and the best way to represent textual data. Strings should not be used to represent:
enum). E.g. no "cm", "mm", "km" as units. Use a Unit enum with these elements. Unit.cm, etc.int, double, etc.)Date, Calendar or joda-time DateTime)char[] instead, as strings are handled differently by the JVM and the sensitive information may become accessible to an attacker.byte[], you should not use a new String(bytes) to transfer it - you can loose information that way. Strings can represent binary content, if it is encoded - in Base64, Hex, etc.
If you are asking if
...
public enum Settings {
FAST,SLOW,PRECISE
}
...
if(setting == Settings.FAST) {
...
}
is better than
...
if("FAST".equals(setting)) {
...
}
...
Then the answer is yes, enum is better, because you can compare with == instead of .equals() which probably makes the executable faster and is easier to write, plus you can use switch where with string values you cannot, and with enum you can leverage a good IDE like NetBeans or Eclipse to help you avoid typos that would get past the IDE and the compiler if you are checking for String values instead of your enum Flags.
java.lang.String is not evil. In fact, it's probably the most commonly used class in java (Disclaimer: I have no data to back that up). However, there are some considerations:
It would seem logical to collect and store the password in an object of type java.lang.String. However, here's the caveat: Objects of type String are immutable, i.e., there are no methods defined that allow you to change (overwrite) or zero out the contents of a String after usage. This feature makes String objects unsuitable for storing security sensitive information such as user passwords. You should always collect and store security sensitive information in a char array instead.
-- http://docs.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide.html#PBEEx
When concatenating Strings, you should probably use StringBuilder since java.lang.String is immutable and new copies are made for each concatenation.
When a more specialized class exists, e.g. enums, numbers, dates, etc., prefer it over String.
One unfortunate aspect of using String is that prior to JDK 7 it doesn't work in a switch...case statement; you must (if using Strings for this purpose) use if...else if...else instead. And you must test with .equals() instead of ==, and under some situations you may want to use .equalsIgnoreCase() instead. All of these incline me to prefer enum to String for such situations.
It depends. Out of mind and assuming this list is not exhaustive.
Pros:
Java SE 7: String - The String class is immutable so Strings can be shared (this also implies thread safety).
String pool in Java - Strings are pooled so it is efficient when re-using them.
Cons:
Concat operations are not efficient when using + for multiple Strings.
It is better to use a StringBuilder or a StringBuffer (thread-safe) or Ropes.
See this: IBM: Ropes
String is not evil in and of itself.
I think the harm comes when you use it as your primary abstraction. You see it in code where there are lots of primitives (e.g. Strings, ints, arrays, data structures) that are obviously related, but are scattered throughout code.
A better solution in those cases is to encapsulate data items that belong together into a sensible object.
