When I review Java codebases, I often see string joining done in three different ways within the same file. That inconsistency is a quiet bug factory: it makes behavior around nulls, performance, and readability unpredictable. The difference between String.concat() and the + operator is small on the surface but big in real systems. I have shipped services where a single null value slipped into a concat() call and crashed a request path, while the same code path using + would have quietly produced the literal "null" in logs. That might sound minor, but in production, the difference between a 500 and a readable log line is everything.
If you want to make dependable choices, you need to know how each approach behaves, how the compiler rewrites it, and how it interacts with nulls, types, and performance under load. I will walk through the mechanics, show complete runnable examples, highlight pitfalls I see in code reviews, and give direct guidance on what to use in 2026 code. I will also connect these choices to modern tooling like IDE inspections and AI assistants, because the fastest way to fix string concatenation issues is to catch them before they ship.
Strings as objects: the groundwork that makes concatenation tricky
Java strings are immutable. Every time you "change" a string, the JVM creates a new String instance with a new character array (or byte array under compact strings). That immutability is a huge benefit for thread safety and caching, but it means concatenation always creates new objects. Whether you use concat() or +, you are creating new string objects, and the cost depends on how many intermediate objects you create.
A simple analogy I like: imagine each string is a sealed envelope. If you want to add a new letter to the end, you cannot open the envelope and drop it in. You must create a brand-new envelope that contains the old letters plus the new one. The question is not whether a new envelope is created, but how many envelopes you create along the way.
Both concat() and + ultimately build new strings. The differences are in method signature, null handling, type conversions, and how the compiler rewrites the code. Once you know those differences, you can predict behavior without guessing.
The concat() method: narrow, strict, and predictable
concat() is a method on String. It takes exactly one argument, and that argument must be a non-null String. If the argument is null, you get a NullPointerException. If the argument is not a String, you get a compile-time error. That strictness is both a strength and a risk.
When I want strictness in a public API or a low-level library method, concat() is a good signal. It says, "I expect a real string here. Nulls are not part of the contract." That clarity can prevent hidden bugs. But if you are not controlling the input, this strictness can cause a runtime crash.
Here is a complete example that shows what I mean:
public class ConcatStrictDemo {
public static void main(String[] args) {
String prefix = "Order-";
String id = "A19";
System.out.println(prefix.concat(id));
// Uncomment to see the crash
// String missing = null;
// System.out.println(prefix.concat(missing));
}
}
If missing is null, the second call throws a NullPointerException at runtime. That is a hard failure. If your goal is to fail fast and keep data quality high, this is perfect. If your goal is to keep a process running even with partial data, this is a risk.
The narrow signature also has a usability impact. If you need to concatenate a number, concat() forces you to convert it yourself:
public class ConcatTypeDemo {
public static void main(String[] args) {
String message = "Retries: ";
int count = 3;
// Must convert explicitly
String result = message.concat(String.valueOf(count));
System.out.println(result);
}
}
That explicit conversion is clear and safe, but it adds noise in code that is already heavy with formatting logic.
The + operator: flexible and compiler-friendly
The + operator is part of the Java language, not the String API. It works with strings because the Java compiler transforms string concatenation into StringBuilder (or StringBuffer in some older cases). The operator allows you to combine strings with any other type, and it converts those values to strings for you.
That flexibility is very convenient, especially when building log messages or dynamic labels:
public class PlusOperatorDemo {
public static void main(String[] args) {
String user = "Ava";
int retries = 2;
boolean cached = true;
String message = "User=" + user + ", retries=" + retries + ", cached=" + cached;
System.out.println(message);
}
}
This is easy to read and avoids explicit String.valueOf calls. It also has a subtle runtime behavior: if any operand is null, the result includes the literal string "null". That can be helpful or harmful depending on context.
Example:
public class PlusNullDemo {
public static void main(String[] args) {
String status = null;
System.out.println("Status=" + status);
}
}
This prints Status=null and does not throw. In a logging context, that might be exactly what you want. In a user-facing string, it is a mess.
The + operator is also more permissive with argument count. You can chain many concatenations in a single expression. The compiler will convert it into something like:
StringBuilder sb = new StringBuilder();
sb.append(a);
sb.append(b);
sb.append(c);
return sb.toString();
This is a key point: for a single expression, the compiler does the right thing. But if you concatenate in a loop, you need to switch to StringBuilder yourself. The operator will not rescue you in that case.
Differences that matter in real systems
Let me break down the differences I see most often in production code, and why they matter.
1) Argument handling: one vs many
concat() accepts exactly one String. + can join multiple values in a single expression and can accept any type.
When you have many pieces, + is simply less clutter. But in a method that expects a single non-null string, concat() makes that expectation crystal clear. I often use concat() in small, low-level helpers, and + in higher-level formatting code.
2) Type conversion rules
concat() only accepts a String. If you pass anything else, you must convert it first. The + operator does the conversion automatically using String.valueOf on each operand.
This matters with numbers and objects. For example, if an object overrides toString(), + will call it. That can be expensive or unsafe if toString() has side effects. With concat(), you are forced to choose a conversion, which can make those decisions explicit.
3) Null behavior
This is the biggest behavior gap.
concat()throwsNullPointerExceptionif the argument is null.+converts null to the literal string "null" and continues.
I use that difference to enforce contracts. If a value must not be null, I prefer concat() or explicit validation. If I am in a logging or tracing path where I want to avoid crashing a request, I prefer + combined with good formatting.
4) Performance and memory
For a simple expression, + and concat() are both fine. The JVM creates a new string either way, and the compiler will generate a StringBuilder for the + case. concat() is a single method call that may allocate a new string by copying bytes.
The performance difference between the two for small concatenations is usually negligible. In my profiling work, you rarely see a direct win from switching between these two. The bigger issue is when concatenation happens in a loop or hot path, where repeated allocations and copying add up. That is not a concat() vs + problem, it is a StringBuilder vs repeated concatenation problem.
For example:
public class LoopConcatDemo {
public static void main(String[] args) {
String result = "";
for (int i = 0; i < 1000; i++) {
result = result + i + ","; // Avoid this
}
System.out.println(result.length());
}
}
This creates a lot of intermediate strings. The fix is StringBuilder:
public class LoopBuilderDemo {
public static void main(String[] args) {
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
sb.append(i).append(‘,‘);
}
System.out.println(sb.length());
}
}
The takeaway: the operator choice matters less than your overall concatenation pattern.
How the compiler rewrites + and why it matters
Modern Java compilers convert string concatenation with + into StringBuilder chains. That transformation makes simple concatenation efficient, but it only applies within a single expression.
Example:
String s = "A" + value + "B";
This becomes something like:
StringBuilder sb = new StringBuilder();
sb.append("A");
sb.append(value);
sb.append("B");
String s = sb.toString();
If you write concatenation across multiple statements, each statement creates its own builder and then creates a string. That is why loops are so costly when you use +.
concat() does not gain special compiler treatment. It is a method call, so the compiler does not rewrite it into a builder in the same way. The JIT may inline it, but you should not rely on that for performance. If performance is a concern, StringBuilder is still the right tool.
Practical guidance: what I use and why
In 2026, I follow a simple rule set that keeps code predictable and easy to review:
1) For short, readable concatenations in a single expression, I use +.
2) For loops or repeated concatenation, I use StringBuilder.
3) For strict API contracts where null is not allowed, I use concat() or explicit validation.
4) For user-facing strings where nulls should be visible but not crash the app, I use + with clear formatting or String.valueOf explicitly.
If you are writing a library method that might be reused widely, clarity beats brevity. concat() can signal strictness, but I often go further and validate with Objects.requireNonNull to make intent obvious:
import java.util.Objects;
public class LabelBuilder {
public static String buildLabel(String prefix, String name) {
Objects.requireNonNull(prefix, "prefix");
Objects.requireNonNull(name, "name");
return prefix.concat(name);
}
}
That pattern gives you a clear error message instead of a generic NullPointerException with a stack trace inside String.concat.
Common mistakes I see in code reviews
Here are the mistakes I see most often, and how I fix them.
Mistake 1: Using concat() with nullable data
If you do this in a service layer that consumes data from a database or API, you are asking for a production exception. My fix is either to guard against nulls or use + where a literal "null" is acceptable.
Example fix:
public class SafeConcatDemo {
public static void main(String[] args) {
String name = null;
String label = "Name: " + name; // Produces "Name: null" instead of crashing
System.out.println(label);
}
}
If you do not want "null" in output, you should default it:
public class SafeDefaultDemo {
public static void main(String[] args) {
String name = null;
String safeName = (name == null) ? "(unknown)" : name;
System.out.println("Name: " + safeName);
}
}
Mistake 2: Using + inside loops
The code will work, but it creates many intermediate strings and wastes memory. Replace it with StringBuilder.
Mistake 3: Confusing concat() with StringBuilder.append
I still see developers assume concat() mutates the original string. It does not. Always remember that String is immutable.
Mistake 4: Concatenating large strings in high-throughput logging
Even when using +, a log statement like logger.info("User=" + user + " payload=" + payload) builds the string even if the log level is disabled. Prefer parameterized logging APIs if you are in a performance-sensitive path. In 2026, most logging frameworks support lazy evaluation or structured fields.
Side-by-side behavior table
Here is a quick comparison you can use as a decision guide:
concat()
+ operator —
Exactly one
String only
Throws NullPointerException
Explicit, strict
No special rewrite
StringBuilder for a single expression Strict API contracts
Notice that the table does not claim a big performance win for either side. In normal code, the difference is not about speed. It is about correctness and readability.
Real-world scenarios and how I decide
Let me show a few realistic scenarios and how I choose.
Scenario 1: Formatting a response label
You are building a label for a response that will be sent back to a client. Nulls should be visible but not crash the service. I use + with defaults if needed:
public class ResponseLabelDemo {
public static void main(String[] args) {
String userId = null;
String safeId = (userId == null) ? "(missing)" : userId;
String label = "UserId=" + safeId;
System.out.println(label);
}
}
Scenario 2: Internal utility with strict contracts
You are writing an internal method that combines two known non-null strings. I use concat() and explicit null checks for clarity:
import java.util.Objects;
public class StrictJoiner {
public static String joinKey(String left, String right) {
Objects.requireNonNull(left, "left");
Objects.requireNonNull(right, "right");
return left.concat("::").concat(right);
}
}
Scenario 3: Concatenation in a loop
Use StringBuilder, not + or concat().
public class CsvBuilder {
public static void main(String[] args) {
String[] users = {"Ava", "Liam", "Noah"};
StringBuilder sb = new StringBuilder();
for (int i = 0; i < users.length; i++) {
if (i > 0) {
sb.append(‘,‘);
}
sb.append(users[i]);
}
System.out.println(sb.toString());
}
}
Edge cases you should test
When I write tests around string concatenation, I focus on the following:
1) Null input: verify behavior is either a clear error or a safe string.
2) Non-string types: confirm conversion is correct when using +.
3) Empty strings: confirm concatenation does not insert unexpected separators.
To make that last point concrete, I like tests that cover both empty strings and whitespace strings. They behave the same in concatenation but very differently in user interfaces. If you expect a label to be visible, a string of spaces is still visually empty, so the semantics matter.
Here is a minimal, runnable test-style example:
public class EdgeCaseDemo {
public static void main(String[] args) {
String empty = "";
String space = " ";
String nullValue = null;
System.out.println("Empty:" + empty + "");
System.out.println("Space:" + space + "");
System.out.println("Null:" + nullValue + "");
// concat() strictness
// System.out.println("X".concat(nullValue)); // throws NPE
}
}
That simple output instantly shows how invisible values propagate. It is a low-effort test that catches a surprising amount of formatting bugs.
A deeper dive into null handling and intent
Null is the fulcrum of this whole decision. I treat concat() and + as tools that encode intent about nulls, and I use that to signal contracts to other developers.
When I want nulls to explode
In a strict domain model or a low-level parser, I want nulls to be loud. If a key should never be null, the best outcome is an early failure with a clear error. I often pair concat() with a precondition check.
import java.util.Objects;
public class AccountId {
public static String format(String region, String id) {
Objects.requireNonNull(region, "region is required");
Objects.requireNonNull(id, "id is required");
return region.concat("-").concat(id);
}
}
This makes it obvious to a reader that null is invalid and caught at the boundary.
When I want nulls to survive
In logging, tracing, or support tooling, I almost never want a null to crash the code path. I want to see it in output and keep moving. That is where + shines.
public class SupportLog {
public static void main(String[] args) {
String userId = null;
String sessionId = "S-17";
System.out.println("userId=" + userId + ", sessionId=" + sessionId);
}
}
If that line was in concat() form, a null user id would kill the log line entirely. With +, it prints userId=null and gives you a clue. I have debugged more production incidents using that exact clue than I can count.
When I want nulls to default
Sometimes I do not want nulls to crash or appear as literal text. I want a domain default. That is a separate choice from + vs concat(). It is the choice of how you normalize data.
public class Defaulting {
public static String safe(String value, String fallback) {
return value == null ? fallback : value;
}
public static void main(String[] args) {
String city = null;
String label = "City=" + safe(city, "(unknown)");
System.out.println(label);
}
}
This is a pattern I prefer over sprinkling null checks across concatenation expressions.
Type conversion: the hidden cost of convenience
The + operator does automatic type conversion by calling String.valueOf(...) on each operand. That is extremely convenient, but it hides a couple of behaviors that matter in edge cases.
String.valueOf vs toString
For non-null objects, String.valueOf(obj) is effectively obj.toString(). For null, it returns the string "null". This is why the + operator behaves the way it does with nulls.
This can surprise you with complex objects. If an object has a heavy toString() implementation (for example, building a JSON view of itself), a single + can become expensive. I have seen log statements that accidentally serialize entire payloads when a small ID was expected.
Autoboxing and number formatting
The + operator converts primitives and boxed types to strings. That conversion uses the standard formatting for numbers, which is usually fine but can be a subtle mismatch if you expected a specific format or locale. If you need a specific format, use String.format or a formatter explicitly rather than relying on +.
Character and boolean surprises
‘A‘ + "" produces "A" because the empty string is a string, but ‘A‘ + 1 yields an integer arithmetic result (66). This is not a concat() vs + difference in practice, but it is a place where people assume they are doing concatenation and accidentally do math. The rule of thumb: if at least one operand is a String, concatenation happens; otherwise numeric addition occurs.
Here is a quick demo that I use when teaching juniors:
public class PlusRulesDemo {
public static void main(String[] args) {
System.out.println(‘A‘ + 1); // 66
System.out.println(‘A‘ + ""); // A
System.out.println(1 + 2 + "3"); // 33
System.out.println("1" + 2 + 3); // 123
}
}
The last two lines are the most surprising. 1 + 2 + "3" performs numeric addition before it sees a string, while "1" + 2 + 3 produces a concatenation chain. That is a + operator nuance worth remembering when you build labels or IDs.
Performance considerations you can actually apply
Performance discussions around strings often become abstract. I prefer concrete rules you can apply without micro-benchmarking.
Rule 1: One expression is fine
If you are concatenating a handful of pieces in a single expression, + is perfectly fine. The compiler will create a StringBuilder and the JIT will optimize it. You do not need to micro-optimize by switching to concat() or even manual StringBuilder.
Rule 2: Loops need builders
If you are concatenating inside a loop, use StringBuilder (or StringBuffer only if you need synchronization). This is the biggest real-world win, because it avoids a cascade of temporary strings.
Rule 3: Prefer builders for high-frequency concatenation
If the code runs in a hot path or tight loop, use StringBuilder. The readability cost is small compared to the performance gain under load.
Rule 4: Avoid string building before you know it will be used
For logging, metrics, or tracing, avoid concatenating the string before you know you will emit it. Most logging frameworks support parameterized messages, which avoid building the string if the level is disabled.
// Instead of:
logger.debug("User=" + user + ", payload=" + payload);
// Prefer:
logger.debug("User={}, payload={}", user, payload);
The decision here is not about concat() vs +, but about avoiding work entirely.
Rule 5: Do not optimize away correctness
I have seen teams switch + to concat() hoping for a performance win and then trigger null crashes. That is a net negative. Fix correctness first, and only then consider micro-optimizations.
The hidden differences in bytecode and JIT behavior
You do not need to read bytecode daily, but understanding the shape of what the compiler emits helps explain why + is usually good enough.
If you compile a simple + expression, the compiler generates StringBuilder calls. That is why a single expression is efficient: the builder exists for the duration of the expression and then is thrown away. The JIT can inline those calls, and the builder may be stack-allocated depending on the optimization tier.
concat() is a direct method call on String. It still has to allocate a new string and copy characters. There is no magic shortcut. In practice, both are fine for small concatenations. The bigger difference is how they handle nulls and types, not raw speed.
Alternative approaches beyond concat() and +
When you build bigger strings or want more explicit control, you have other tools. I am including these because many real systems should not be using either concat() or + in isolation.
StringBuilder and StringBuffer
I already mentioned StringBuilder, but it is worth emphasizing: this is the primary tool for building strings in loops or when you are assembling many segments. StringBuffer is synchronized, so it is rarely needed in modern Java unless you are in legacy code or you truly need thread-safe mutation.
StringBuilder sb = new StringBuilder(128); // optional capacity hint
sb.append("prefix");
sb.append(id);
sb.append(‘:‘);
sb.append(value);
String result = sb.toString();
I sometimes give the builder a capacity hint when I know the approximate length. It is optional, but it avoids occasional reallocations in hot code.
String.join for lists
When you have a list of strings, String.join is concise and readable. It also handles empty lists cleanly.
import java.util.List;
List tags = List.of("red", "blue", "green");
String joined = String.join(",", tags);
This is cleaner than manual loops and prevents common separator bugs.
String.format or formatters for structured output
If you need alignment, precision, or locale-specific formatting, String.format (or Formatter) is clearer than a long chain of +. It is not necessarily faster, but it is explicit.
String result = String.format("User=%s retries=%d", user, retries);
Use it where readability or formatting rules matter more than raw speed.
Text blocks for static templates
In modern Java, text blocks let you build multi-line strings without concatenation. If you have a static template or a multi-line JSON, use a text block and then insert values with .formatted(...) or another method. That can be clearer than concatenating line by line.
Practical recipes I use in production
Here are the exact patterns I use most often in real systems. These are the simple, repeatable recipes that keep things consistent.
Recipe 1: Safe label builder with defaults
public class Labels {
public static String label(String key, String value) {
String safeValue = value == null ? "(unknown)" : value;
return key + "=" + safeValue;
}
}
This is intentionally not using concat() because I want nulls to be handled gracefully. The result is stable and easy to log.
Recipe 2: Strict internal keys
import java.util.Objects;
public class Keys {
public static String key(String a, String b) {
Objects.requireNonNull(a, "a");
Objects.requireNonNull(b, "b");
return a.concat(":").concat(b);
}
}
This forces a failure if the inputs are wrong. It keeps the contracts strict where correctness matters.
Recipe 3: Builder for repeated appends
public class PayloadBuilder {
public static String build(int count) {
StringBuilder sb = new StringBuilder(64);
for (int i = 0; i < count; i++) {
if (i > 0) sb.append(‘,‘);
sb.append(i);
}
return sb.toString();
}
}
No + or concat() inside the loop. This is the best pattern for performance and readability.
Recipe 4: Logging with parameterized messages
// Pseudocode for a typical logging API
logger.info("User={}, retries={}, cached={}", user, retries, cached);
This avoids building a string when the log level is off. It also avoids null surprises because the framework does the string conversion.
A quick checklist I use during code reviews
If I am reviewing a PR that touches string concatenation, I scan with a checklist. It is short but effective.
1) Is there concatenation inside a loop? If yes, prefer StringBuilder.
2) Is there a use of concat() with possible nulls? If yes, add validation or use defaults.
3) Is a + chain building large output in a hot path? If yes, consider a builder or streaming output.
4) Is the code user-facing? If yes, avoid literal "null" unless it is an explicit choice.
5) Is the code logging? If yes, prefer parameterized logging.
These checks catch 90% of the issues I see without slowing the review down.
Modern tooling and AI-assisted workflows
I now treat string concatenation as a lintable surface. IDEs and static analysis tools can detect common issues, and AI assistants can auto-suggest fixes when the code is clear about intent.
IDE inspections
Most IDEs can flag string concatenation in loops or detect redundant String.valueOf calls. I keep those inspections on. They catch subtle performance issues before they hit production.
Static analysis rules
If your team uses static analysis, you can enforce a rule that discourages + in loops or flags concat() usage with nullable values. This sounds strict, but it is incredibly effective. It is also a great way to align team conventions across a large codebase.
AI code assistants
AI assistants can suggest StringBuilder refactors or detect risky null concatenations. The catch is that they only work well if your code has clear intent. If you mix concat() and + without a consistent pattern, the suggestions become noisy. Consistency matters.
Practical warnings and "gotchas" that still surprise people
Even experienced developers can get bitten by a few edge cases. These are the ones I still see in the wild.
null + "" is not a crash
It is easy to forget that "" + null is valid and produces "null". That can sneak into user interfaces if you are not careful. If you care about UX, normalize the data first.
concat() with empty strings still allocates
"abc".concat("") returns a new string or the same string depending on internal optimizations, but you should not depend on that. If you care about micro-allocations, keep the code simple and let the JVM handle it.
+ chain evaluation order matters
1 + 2 + "3" equals "33", not "123". This is a classic bug in ID formatting, and it still appears in production code.
toString() side effects
Sometimes toString() is expensive or triggers unexpected behavior. When you use +, you implicitly call toString(). If an object does heavy formatting, you might want to control that explicitly rather than rely on implicit conversion.
Decision guide: what to use and when
If you want a single mental model that you can share with your team, here is the compact decision guide I recommend.
1) Single expression, short output, readability matters: use +.
2) Strict contract, nulls are illegal: use concat() with Objects.requireNonNull.
3) Loop or repeated concatenation: use StringBuilder.
4) Logging or tracing: use parameterized logging.
5) Complex formatting with precision or locale: use String.format or a formatter.
That is it. You do not need a more complex decision tree than this.
Expanded examples: from toy to production-ready
A short example is great for teaching, but production code has constraints: error handling, null policies, and logging. Here are more complete examples that show those constraints in context.
Example 1: Building a cache key
You want a key composed of multiple parts that must be non-null. The key should never include the literal "null" because it would create collisions.
import java.util.Objects;
public class CacheKey {
public static String build(String region, String tenant, String id) {
Objects.requireNonNull(region, "region");
Objects.requireNonNull(tenant, "tenant");
Objects.requireNonNull(id, "id");
return region.concat(":")
.concat(tenant)
.concat(":")
.concat(id);
}
}
This is a clean use of concat() because the contract is strict, and the inputs are validated.
Example 2: User-facing status line
You want a status line that should not crash if an optional field is missing, but you also do not want literal "null" to appear.
public class StatusLine {
public static String safe(String value) {
return value == null ? "(unknown)" : value;
}
public static String build(String name, String state, Integer retries) {
return "Name=" + safe(name) +
", state=" + safe(state) +
", retries=" + (retries == null ? "(n/a)" : retries);
}
}
This uses + because readability matters, and the nulls are explicitly handled in a user-friendly way.
Example 3: Efficient large output
You want to build a large CSV for export. This is a clear StringBuilder case.
import java.util.List;
public class CsvExport {
public static String toCsv(List rows) {
StringBuilder sb = new StringBuilder(1024);
for (int i = 0; i < rows.size(); i++) {
String[] row = rows.get(i);
for (int j = 0; j < row.length; j++) {
if (j > 0) sb.append(‘,‘);
sb.append(row[j] == null ? "" : row[j]);
}
if (i < rows.size() - 1) sb.append('\n');
}
return sb.toString();
}
}
This avoids the performance pitfalls of + and avoids concat() null crashes.
Subtleties in chaining concat()
Some people avoid concat() because it only takes one argument, but you can chain it. The chain is readable for short cases and can be clearer than multiple + operators.
String full = first.concat(" ").concat(last);
This is clean when there are two or three segments. Once you have more pieces or mixed types, the + operator is usually easier to scan, or you should switch to a builder.
When not to use either
There are cases where neither concat() nor + is the best choice.
- When building JSON, use a JSON library rather than string concatenation. It avoids escaping bugs.
- When building SQL, use prepared statements, not concatenated strings. This is a security issue, not just a style issue.
- When building large text output, use streaming or builders to avoid memory spikes.
Those decisions are about correctness and security, not just string mechanics.
A short note on readability and team conventions
One of the biggest wins in large Java projects is consistency. If your team decides to use + for simple concatenations and StringBuilder for loops, and to reserve concat() for strict contracts, your reviews become faster and your codebase becomes more predictable. The specific choice matters less than the consistency of the choice. I would rather see a codebase that consistently uses + with careful null handling than a codebase that swings between patterns with no clear rationale.
Summary: the difference in one paragraph
String.concat() is strict: it takes a single non-null string and fails fast if you violate that contract. The + operator is flexible: it accepts any type, converts it to a string, and turns nulls into the literal "null." For short, readable expressions, + is excellent. For strict contracts and clear null enforcement, concat() is a strong signal. For loops or heavy concatenation, use StringBuilder. Most performance problems are about patterns, not about concat() vs +. If you keep those rules in mind, you will avoid the most common production bugs and keep your code easy to read.
Expanded checklist for teams
I close with a checklist you can copy into your team docs or code review guide. It is short, but it makes decisions consistent across a large codebase.
1) Use + for short, single-expression concatenation.
2) Use StringBuilder in loops or when concatenating many parts.
3) Use concat() only when inputs are guaranteed non-null and you want that strictness.
4) Avoid literal "null" in user-facing text; default or validate.
5) Avoid building strings for disabled log levels; use parameterized logging.
6) Prefer libraries over manual concatenation for JSON, SQL, and CSV when correctness matters.
If you follow that list, you will make fewer mistakes, read code faster, and reduce the number of "string glue" bugs that slip into production.
