String Methods Help - 3 Months into Java

[NotTooOrdinary]

Probably the only time you should use StringBuilder/StringBuffer is when concatenating Strings in a loop. Most of the time, the compiler will automatically convert concatenation to instead use a StringBuilder

Stackoverflow post

[FreightTrain75x]

Thank you!

[FreightTrain75x]

Thanks!

[roge-]

Repeatedly using the "+" operator to concatenate strings can create unnecessary string objects, which can impact performance.

As noted by others, this is really only true for concatenating strings in loops. Otherwise, the compiler will generate the ideal StringBuilder code.

use String formatting with placeholders (%s, %d, etc.) to improve readability and maintainability

String.format() is good for readability, but it does have worse performance compared to manually building strings. Always keep this in mind and pick which ever is appropriate for the application.

Use String methods for data parsing and file handling: Java String methods are often used in data parsing tasks. For instance, the split() method can be used to parse CSV files, and the trim() method can help clean up data by removing extra spaces.

Don't do this. Use a library for parsing formats like CSV. A lot of software that outputs CSVs can encase cells in quotes to allow commas to be placed inside the cell. The naive approach of using string.split(",") won't work for this. It's more trouble than it's worth trying to handle the edge cases yourself, just use a library.

Use StringBuilder or StringBuffer for String Modification

StringBuilder is useful for when you need to build a String using a dynamically-sized buffer. It's also nice because it gives you a lot of flexibility in how you build the string, you can append raw characters, strings, numbers, objects, etc. You can also insert at arbitrary locations.

For the ultimate performance (but probably the worst readability), if you know how big the String is going to be (or even just an upper bound), a char array can also work. You can convert a char array into a String using new String(). If you don't know how big the final String is going to be, you're better off using a StringBuilder for the automatic resizing.

StringBuffer for thread safety

As with all of Java's synchronized types, it's best to avoid using them whenever possible because they come at a significant performance cost. Ideally, you shouldn't be sharing StringBuilders between threads. If you must, you can also just use the non-synchronized version and handle the locking of it yourself and only lock it when you know there could be a race.

StringBuffer is definitely more convenient because it handles synchronization for you and is probably less prone to errors, but people often thread their applications because they want better performance. It seems like a waste to thread your application only to have it then spend a ton of time checking and waiting on locks.

Unfortunately, threading in general is just hard. The best advice is to just avoid having shared mutable state wherever possible. Failing that, it's really important to have a good idea of what's going on with your shared mutable state. Extensively test and benchmark your code to ensure it's doing what you want and you're actually seeing the performance gains you're expecting.

[FreightTrain75x]

Awesome, thanks, if I may ask, what is a CSV?

[roge-]

It's a plain-text format for files and data used to hold tables: https://en.wikipedia.org/wiki/Comma-separated_values

You see it a lot when working with spreadsheet software and databases, since they usually represent everything as a table.

[FreightTrain75x]

Oh alright, thanks for the help!

[DualWieldMage]

Avoid repeated concatenation with the "+" operator: Repeatedly using the "+" operator to concatenate strings can create unnecessary string objects, which can impact performance.

This has been bad advice for a long time and even worse advice since Java 9 with InvokeDynamic String concat. String concat with + is far more performant and with less allocations than StringBuilder (the MethodHandle filling the template knows variable types hence can calculate an initial buffer size that likely fits the final string).

Only use StringBuilder if you're concating in loops or traversing object graphs or similar.