This immutability is essential to understand when dealing with large-scale operations on Strings. Improper handling, like frequent concatenation, can result in excessive memory usage and poor performance. Let\u2019s dive into best practices for managing large Strings efficiently.<\/p>\n\n\n\n
String favoriteColor = \u201cred\u201d;\nfavoriteColor = \u201cgreen\u201d;<\/code><\/pre>\n\n\n\nBut you have to remember that the second assignment actually creates a new<\/em> String (the value \u201cgreen\u201d), and reassigns favoriteColor (the reference) to that value. The old String (the value \u201cred\u201d) is orphaned and will eventually be garbage collected<\/a>.<\/p>\n\n\n\nThis is why concatenating Strings many, many, many times is a bad idea. Each time you concatenate, your application takes the hit of implicitly making a new String. Let\u2019s look at an example where we want to read in the long file of HTML colors, named \u201ccolorNames.dat\u201d:<\/p>\n\n\n\n
AliceBlue\nAntiqueWhite\nAntiqueWhite1\nAntiqueWhite2\nAntiqueWhite3\nAntiqueWhite4\naquamarine1\naquamarine2\naquamarine4\nazure1\nazure2\nazure3\nazure4\nbeige\nbisque1\n...<\/code><\/pre>\n\n\n\nThe ColorList class reads each line of this file and makes one long String, complete with newline characters.<\/p>\n\n\n\n
class ColorList {\n String getAllColors(String filename) throws FileNotFoundException, IOException {\n String retVal = \"\";\n BufferedReader br = new BufferedReader(new InputStreamReader(this.getClass().getResourceAsStream(filename)));\n for(String line; (line = br.readLine()) != null; ) {\n \u00a0\u00a0\u00a0retVal += line + \"\\n\";\n }\n return retVal;\n }\n }<\/code><\/pre>\n\n\n\nNote that the line inside of the for loop is actually creating four<\/strong> new Strings: One for the contents of the line, one for the newline character, one that combines them both, and one that appends that String to the current contents of retVal. To make matters worse, the old contents of retVal are then thrown away and replaced with this new String. No bueno!<\/p>\n\n\n\nThis process results in excessive memory usage and performance degradation, especially for large files. The solution to this kind of problem is to use StringBuffer \u2013 or the newer, similarly-named StringBuilder.<\/p>\n\n\n\n
Use StringBuilder or StringBuffer<\/strong><\/h3>\n\n\n\nBoth define themselves as \u201ca mutable sequence of characters\u201d, which solves the immutability problem.<\/p>\n\n\n\n
\n- StringBuffer:<\/strong> StringBuffer has existed since Java 1.0 and is thread-safe, meaning that threads sharing a \u201cconsistent and unchanging view of the source\u201d can safely access and operate on the StringBuffer object. To keep things simple, and generally more performant, the documentation recommends using StringBuilder instead.<\/li>\n\n\n\n
- StringBuilder:<\/strong> Introduced in Java 1.5, StringBuilder has the same interface as its predecessor but is not thread-safe because it doesn\u2019t guarantee synchronization. Assuming you\u2019re trying to build a very large String from a single source (such as a file or database), it\u2019s usually sufficient to assign that job to a thread and walk away. StringBuilder is perfectly suitable for that job, and we prefer to use it over StringBuffer when we can.<\/li>\n<\/ul>\n\n\n\n
class ColorList {\n String getAllColors(String filename) throws FileNotFoundException, IOException {\n StringBuilder retVal = new StringBuilder();\n BufferedReader br = new BufferedReader(new InputStreamReader(this.getClass().getResourceAsStream(filename)));\n for(String line; (line = br.readLine()) != null; ) {\n retVal.append(line);\n retVal.append(\"\\n\");\n }\n return retVal.toString();\n }\n}<\/code><\/pre>\n\n\n\nIf we crank the number of lines in our colorNames.dat file up to about 122,000 and then compare the concatenate and StringBuilder approaches from the main method:<\/p>\n\n\n\n
public class Main {\n public static void main(String[] args) throws IOException {\n long startTime = System.nanoTime();\n ColorList colorList = new ColorList();\n String allColorNames = colorList.getAllColors(\"colorNames.dat\");\n System.out.print(allColorNames);\n long endTime = System.nanoTime();\n System.out.println(\"Took \"+(endTime - startTime) + \" ns\");\n }\n}<\/code><\/pre>\n\n\n\nWe see that the concatenate approach takes about 50 seconds to execute, while the StringBuilder approach comes in at 0.7 seconds. That performance saving is huuuuge<\/strong>!<\/p>\n\n\n\nThis is a simple and easy-to-measure example. If you\u2019re looking to get a handle on your entire application\u2019s performance problems, check out some beefier performance tools for Java applications<\/a>.<\/p>\n\n\n\nTo Concatenate or Not to Concatenate?<\/strong><\/h3>\n\n\n\nLet\u2019s suppose we want to factor the user\u2019s favorite color into the system\u2019s response, so that it tells the user, \u201cOh yes, ____ is also my favorite color!\u201d You might break this up into two strings: \u201cOh yes, \u201c and \u201cis also my favorite color!\u201d. The result would look something like this:<\/p>\n\n\n\n
Interviewer.color.response.part1=Oh yes,\nInterviewer.color.response.part2=is also my favorite color!\n\nString respondToColor(String color) {\n String part1 = Messages.getString(\"Interviewer.color.response.part1\");\n String part2 = Messages.getString(\"Interviewer.color.response.part2\");\n return part1 + color + \" \" + part2;\n}<\/code><\/pre>\n\n\n\nBut this is bad news for i18n\/l10n, because different languages often rearrange the order of nouns, verbs, and adjectives. Some portions of the message may vary depending on the gender of a noun, the [past\/present\/future] tense in question, or who<\/em> is receiving the message. It\u2019s best to keep messages contiguous and succinct, replacing values only when needed. You can use one of String\u2019s replace functions, but String. format is mainly for this purpose:<\/p>\n\n\n\nInterviewer.color.response=Oh yes, %1$s is also my favorite color!\nString respondToColor(String color) {\n String format = Messages.getString(\"Interviewer.color.response\");\n return String.format(format, color);\n}<\/code><\/pre>\n\n\n\nConcatenation is perfectly fine when used to build small<\/em> Strings meant for computer consumption. Building huge Strings? You\u2019re going to need something better than concatenation there, too.<\/p>\n\n\n\nThis is a simple and easy-to-measure example. If you\u2019re looking to get a handle on your entire application\u2019s performance problems, check out some beefier performance tools for Java applications<\/a>.<\/p>\n\n\n\nString Equality<\/h2>\n\n\n\n
Understanding string equality is vital for writing efficient and error-free Java programs. Since Java Strings are immutable, comparing strings involves evaluating their values rather than their references in memory. <\/p>\n\n\n\n
Best practices dictate always using the .equals<\/strong> method for value comparison to avoid unexpected outcomes, especially when algorithms for searching or sorting rely on this method. <\/p>\n\n\n\nIn this section, you will explore how Java handles string equality, its nuances, and how to implement custom comparison logic when default methods fall short. Let’s recall this classic piece of Java wisdom:<\/p>\n\n\n\n
public class Main {\n public static void main(String[] args) throws IOException {\n String s1 = \"red\";\n String s2 = \"red\";\n if(s1.equals(s2)) {\n System.out.println(\"s1 and s2 have equal values\");\n }\n if(s1 == s2) {\n System.out.println(\"s1 and s2 have equal references\");\n }\n\n System.out.println(\"\");\n String s3 = \"green\";\n String s4 = new String(\"green\");\n if(s3.equals(s4)) {\n System.out.println(\"s3 and s4 have equal values\");\n }\n if(s3 == s4) {\n System.out.println(\"s3 and s4 have equal references\");\n }\n System.out.println(\"\\nDone!\");\n }\n};<\/code><\/pre>\n\n\n\nRunning this yields:<\/p>\n\n\n\n
s1 and s2 have equal values\ns1 and s2 have equal references\ns3 and s4 have equal values\nDone!<\/code><\/pre>\n\n\n\nAlthough s1 and s2 are different variables, Java (in an effort to be efficient and helpful) realizes that s2 contains the same value as s1, so it points it to the same place in memory. This is why it considers them to be the same reference. By contrast, s4 has the same value as s3 but explicitly allocates a new location in memory<\/a> for this value. When the time comes to see if they have the same reference, we see that they do not.<\/p>\n\n\n\nHow Java manages its Strings\u2019 references is generally best left to the compiler, but we must remain aware of it nonetheless. This is why, when we care about two Strings\u2019 respective values<\/em>, we must always use .equals, remembering that algorithms that search or sort Strings will rely on this method as well.<\/p>\n\n\n\nComparing Strings<\/h3>\n\n\n\n
Consider the following example, containing two strings whose values represent \u201cdark blue\u201d in French:<\/p>\n\n\n\n
public class Main {\n public static void main(String[] args) throws IOException {\n String s1 = \"bleu fonce\";\n String s2 = \"Bleu fonce\";\n if(s1.equals(s2)) {\n System.out.println(\"s1 and s2 have equal values\");\n }\n else {\n System.out.println(\"s1 and s2 do NOT have equal values\");\n }\n }\n};<\/code><\/pre>\n\n\n\nThe .equals<\/strong> method compares character-by-character and notices that s1 and s2 are not equal due to the case. The String class offers a convenient method called .equalsIgnoreCase that we can use to ignore the discrepancy. But what happens when we realize that there should actually be an accent on the final character (the correct word in French is \u201cfonc\u00e9\u201d) but we want to continue accepting the old value and consider them both equal?<\/p>\n\n\n\npublic class Main {\n public static void main(String[] args) throws IOException {\n String s1 = \"bleu fonce\";\n String s2 = \"Bleu fonc\u00e9 \u00a0\u00a0\";\n if(s1.equalsIgnoreCase(s2)) {\n System.out.println(\"s1 and s2 have equal values\");\n }\n else {\n System.out.println(\"s1 and s2 do NOT have equal values\");\n }\n }\n};<\/code><\/pre>\n\n\n\nOnce again, these Strings are not exactly<\/em> equal because of the accent character and the whitespace. In this case, we need to specify a way to compare the Strings with a Comparator.<\/p>\n\n\n\nDIY Comparators<\/h3>\n\n\n\n
Comparators are particularly useful when you want to normalize Strings in a certain way before comparing them, but you don\u2019t want that logic littered throughout your code.<\/p>\n\n\n\n
First, we make a class that implements Comparator, which gives the equality logic a nice home. This particular Comparator does everything the default String Comparator would do, except it trims the Strings and compares them case-insensitively.<\/p>\n\n\n\n
public class CloseEnoughComparator implements Comparator<String> {\n \u00a0public int compare(String obj1, String obj2) {\n \u00a0\u00a0\u00a0if (obj1 == null) {\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return -1;\n \u00a0\u00a0\u00a0}\n \u00a0\u00a0\u00a0if (obj2 == null) {\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return 1;\n \u00a0\u00a0\u00a0}\n \u00a0\u00a0\u00a0if (obj1.equals( obj2 )) {\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return 0;\n \u00a0\u00a0\u00a0}\n \u00a0\u00a0\u00a0String s1 = obj1.trim();\n \u00a0\u00a0\u00a0String s2 = obj2.trim();\n \u00a0\u00a0\u00a0return s1.compareToIgnoreCase(s2);\n \u00a0}\n}<\/code><\/pre>\n\n\n\nThen we change the main method to use the Comparator:<\/p>\n\n\n\n
public class Main {\n public static void main(String[] args) throws IOException {\n String s1 = \"bleu fonce\";\n String s2 = \"Bleu fonc\u00e9 \u00a0\u00a0\";\n Comparator<String> comparator = new CloseEnoughComparator();\n if(comparator.compare(s1, s2) == 0) {\n System.out.println(\"s1 and s2 have equal values\");\n }\n else {\n System.out.println(\"s1 and s2 do NOT have equal values\");\n }\n }\n};<\/code><\/pre>\n\n\n\nOnly one problem remains. Running the code above will still fail to consider these two Strings equal because of the accent character. Here\u2019s where collation comes in.<\/p>\n\n\n\n
When and How to Internationalize\/Localize a Java String<\/h2>\n\n\n\n
Internationalization (i18n) is the process of process of providing human-readable Strings in different languages, whereas localization (l10n) takes further geographical and cultural concerns into account.<\/p>\n\n\n\n
Internationalization is coarse whereas localization is granular. For example, the Strings \u201cChoose your favorite color\u201d and \u201cChoose your favourite colour\u201d are both English (i18n). But the former is used in the United States (en-US) and the latter is used in Great Britain (en-GB). (These codes are defined in \u201cTags for Identifying Languages\u201d, as outlined in RFC 5646<\/a>.)<\/p>\n\n\n\nBeyond standard messaging, i18n\/l10n is also extremely important when representing dates\/times and currency. The result of translating Strings into lengthier languages \u2013 say, German \u2013 can cause even the most meticulously think-out UI to be a complete revision while adding support for double-byte character sets (i.e. Chinese, Japanese, Korean) can often require impactful changes throughout your entire stack.<\/p>\n\n\n\n
That said, it obviously isn\u2019t necessary to translate every String in your application \u2013 only the ones that humans will see. <\/p>\n\n\n\n
If, for example, you have a server-side RESTful API<\/a> written in Java, you would either a) look for an Accept-Language header on requests, apply settings as needed, then return a localized response or b) return a generally unaltered response, except for error cases that return an error code (that the front-end then uses to look up a translated String to show to the user). You\u2019d choose b<\/strong> if the front end is known and within your control. You\u2019d choose a<\/strong> if the raw response (even error responses) will be presented wholesale to the user. Or if your API is available to unknown consumers and you aren\u2019t sure how the responses will be used.<\/p>\n\n\n\nExample<\/h3>\n\n\n\n
Java applications that present Strings directly to potentially non-English-speaking humans will, of course, need to be translated. Consider again the example where a user is asked to enter his or her favorite color:<\/p>\n\n\n\n
public class Main {\n public static void main(String[] args) throws IOException {\n Interviewer interviewer = new Interviewer();\n System.out.println(interviewer.askColorQuestion());\n Scanner scanner = new Scanner(System.in);\n String color = scanner.nextLine();\n System.out.println(interviewer.respondToColor(color));\n scanner.close();\n }\n}<\/code><\/pre>\n\n\n\nclass Interviewer {\n String askColorQuestion() {\n return \"Enter your favorite color:\";\n }\n String respondToColor(String color) {\n \/\/You can switch on Strings since Java 7\n switch(color) {\n case \"red\":\n return \"Roses are red\";\n case \"blue\":\n return \"Violets are blue\";\n case \"yellow\":\n return \"Java is awesome\";\n default:\n return \"And so are you\";\n }\n }\n}<\/code><\/pre>\n\n\n\nThe Java IDE I use, Eclipse, provides a nice way to extract the Strings from the Interviewer class.<\/p>\n\n\n
\n![\"Java](\"https:\/\/stackify.com\/wp-content\/uploads\/2017\/07\/img2.png\")
<\/figure><\/div>\n\n\n\u2026and get them into a .properties file that I adjust to look like this:<\/p>\n\n\n\n
Interviewer.color.question=Enter your favorite color:\nInterviewer.color.definition.1=red\nInterviewer.color.definition.2=blue\nInterviewer.color.definition.3=yellow\nInterviewer.color.response.1=Roses are red\nInterviewer.color.response.2=Violets are blue\nInterviewer.color.response.3=Java is awesome\nInterviewer.color.response.default=And so are you<\/code><\/pre>\n\n\n\nUnfortunately, this process makes the Strings no longer constant as far as the switch statement is concerned.<\/p>\n\n\n
\n![\"Java](\"https:\/\/stackify.com\/wp-content\/uploads\/2017\/07\/img3.png\")
<\/figure><\/div>\n\n\nThis is a bit unfortunate, but also an opportunity for us to anticipate that this application may \u2013 at some point in the future \u2013 need to handle more than just three colors. In the Messages class that Eclipse made for me, I add a method that will return any key\/value pair given a prefix:<\/p>\n\n\n\n
public static Map<String, String> getStrings(String prefix) {\n \u00a0Map<String, String> retVal = new HashMap<String, String>();\n \u00a0Enumeration<String> keys = RESOURCE_BUNDLE.getKeys();\n \u00a0while(keys.hasMoreElements()) {\n \u00a0\u00a0\u00a0String key = keys.nextElement();\n \u00a0\u00a0\u00a0if (key.startsWith(prefix)) {\n \u00a0\u00a0\u00a0\u00a0\u00a0retVal.put(key, RESOURCE_BUNDLE.getString(key));\n \u00a0\u00a0\u00a0}\n \u00a0}\n \u00a0return retVal;\n}<\/code><\/pre>\n\n\n\nAnd the Interviewer class uses this to more dynamically look up the user\u2019s response and act on it:<\/p>\n\n\n\n
class Interviewer {\n String askColorQuestion() {\n return Messages.getString(\"Interviewer.color.question\");\n }\n String respondToColor(String color) {\n Map<String, String> colorMap = Messages.getStrings(\"Interviewer.color.definition.\");\n for (String colorKey : colorMap.keySet()) {\n String colorValue = colorMap.get(colorKey);\n if (colorValue.equalsIgnoreCase(color)) {\n String responseKey = colorKey.replace(\"definition\", \"response\");\n return Messages.getString(responseKey);\n }\n }\n return Messages.getString(\"Interviewer.color.response.default\");\n }\n}<\/code><\/pre>\n\n\n\nThe result is that the application can be easily translated. Based on some condition (like an environment variable or user request), you can use Java\u2019s ResourceBundle<\/strong> to load a different properties file that serves up locale-specific messages.<\/p>\n\n\n\nThe Power of Collation<\/h2>\n\n\n\n
Collation is the process of determining order (and thus, equality) given a particular ruleset. You may have heard the term collation used in the context of databases, where there may be a setting to establish the default collation for strings, money, or dates therein.<\/p>\n\n\n\n
In Java, Collator is an abstract class that implements Comparator. That means that we could replace the Comparator Code in the main method. But I\u2019ve opted to keep that interface intact and change the implementation of the compare method instead:<\/p>\n\n\n\n
public class CloseEnoughComparator implements Comparator<String> {\n \u00a0public int compare(String obj1, String obj2) {\n \u00a0\u00a0\u00a0if (obj1 == null) {\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return -1;\n \u00a0\u00a0\u00a0}\n \u00a0\u00a0\u00a0if (obj2 == null) {\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return 1;\n \u00a0\u00a0\u00a0}\n \u00a0\u00a0\u00a0if (obj1.equals(obj2)) {\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return 0;\n \u00a0\u00a0\u00a0}\n\n \u00a0\u00a0\u00a0Collator usCollator = Collator.getInstance(Locale.US);\n \u00a0\u00a0\u00a0usCollator.setStrength(Collator.PRIMARY);\n \u00a0\u00a0\u00a0return usCollator.compare(obj1, obj2);\n \u00a0}\n}<\/code><\/pre>\n\n\n\nA few noteworthy changes here:<\/p>\n\n\n\n
\n- The .trim and the .compareToIgnoreCase have been removed<\/li>\n\n\n\n
- I\u2019ve hard-coded a Locale for illustration purposes \u2013 normally this would be based on some condition (like an environment variable or user request)<\/li>\n\n\n\n
- The strength of the Collator is set to PRIMARY<\/li>\n<\/ul>\n\n\n\n
The strength part is important. Collator provides four strengths from which to choose: PRIMARY, SECONDARY, TERTIARY, and IDENTICAL. The PRIMARY strength indicates that both whitespace and case can be ignored, and that \u2013 for comparison purposes \u2013 the difference between e and \u00e9 can also be ignored. Experiment with different locales and strengths to learn more about how collation works. <\/p>\n\n\n\n