Char Array to String — Zeroing Doesn't Protect Passwords

char[] to String conversion comes up surprisingly often in real codebases. Security-conscious APIs (like Java's own KeyStore and JPasswordField) return passwords as char[] rather than String precisely because char arrays can be zeroed out after use, while String literals are interned and may linger in the heap. Understanding the conversion and knowing which method to use matters for correctness, not just convenience.

Four Methods for char[] to String Conversion

All four methods produce the same output for typical use cases. The differences matter at the margins: performance for large arrays, null-safety, and intent signalling. Here's a closer look at each one and where you'd use it in production.

package io.thecodeforge.strings;

import java.util.Arrays;

public class CharArrayConversionExample {

    public static void main(String[] args) {
        char[] chars = {'T', 'h', 'e', 'C', 'o', 'd', 'e', 'F', 'o', 'r', 'g', 'e'};

        // Method 1: String constructor — most common and idiomatic
        String s1 = new String(chars);
        System.out.println("Constructor: " + s1);

        // Method 2: String.valueOf() — same implementation, cleaner intent
        String s2 = String.valueOf(chars);
        System.out.println("valueOf:     " + s2);

        // Method 3: StringBuilder append — useful when building incrementally
        StringBuilder sb = new StringBuilder();
        sb.append(chars);
        String s3 = sb.toString();
        System.out.println("StringBuilder: " + s3);

        // Method 4: String.copyValueOf() — explicit copy semantics
        String s4 = String.copyValueOf(chars);
        System.out.println("copyValueOf: " + s4);

        // Partial range conversion — constructor with offset and count
        String partial = new String(chars, 3, 8); // offset=3, count=8
        System.out.println("Partial [3,8]: " + partial); // CodeForg

        // Security use case: zero out the char array after conversion
        char[] password = {'s', 'e', 'c', 'r', 'e', 't'};
        String passwordStr = new String(password);
        Arrays.fill(password, '\0');  // Overwrite sensitive data
        System.out.println("Password zeroed: " + Arrays.toString(password));
    }
}

Under the Hood: String Constructor vs String.valueOf()

Many engineers assume these two have different implementations. They don't. Open the OpenJDK source for String.class and you'll see valueOf(char data[]) simply returns new String(data). The only difference is how they handle null.

When you call new String((char[]) null), the JVM immediately throws NullPointerException before the constructor can even check the argument. But String.valueOf handles null differently: it returns the literal string "null". This is consistent with other valueOf methods in Java, but it often surprises developers expecting a null return.

So why have both? Intent. new String(chars) signals "I expect this to be non-null — fail early". String.valueOf(chars) signals "I accept null and want a safe string representation". Pick based on what your downstream code expects.

package io.thecodeforge.strings;

public class NullHandlingExample {
    public static void main(String[] args) {
        char[] nullArray = null;

        // Throws NullPointerException
        // String s1 = new String(nullArray);

        // Returns "null" string
        String s2 = String.valueOf(nullArray);
        System.out.println("valueOf(null): '" + s2 + "'");

        // Check length — it's 4, not 0
        System.out.println("Length: " + s2.length());

        // If you need null propagation:
        String s3 = nullArray == null ? null : new String(nullArray);
        System.out.println("Ternary result: " + s3);
    }
}

Partial Char Array Conversion Using Offset and Count

Sometimes you have a char[] that contains more data than you need. Maybe you're parsing a fixed-width record from a mainframe, or you've received a buffer that includes headers. The String constructor accepts an offset and count: new String(chars, offset, length). This creates a String using only a subset of the array, starting at offset and taking length characters.

This is not the same as copying the array and then calling substring. The constructor directly reads only the specified range, avoiding an intermediate copy. It's both memory-efficient and faster than the alternative.

Watch out: if offset + count exceeds chars.length, you'll get a StringIndexOutOfBoundsException. Always validate bounds in production code, especially when the offset comes from untrusted input.

package io.thecodeforge.strings;

public class PartialConversionExample {
    public static void main(String[] args) {
        char[] buffer = {'S', 'T', 'A', 'R', 'T', 't', 'h', 'e', 'C', 'o', 'd', 'e', 'F', 'o', 'r', 'g', 'e', 'E', 'N', 'D'};
        int headerSize = 5; // 'START'
        int trailerSize = 3; // 'END'
        int dataOffset = headerSize;
        int dataLength = buffer.length - headerSize - trailerSize;

        // Convert only the data portion
        String data = new String(buffer, dataOffset, dataLength);
        System.out.println("Data portion: " + data); // theCodeForge

        // Unsafe — this throws StringIndexOutOfBoundsException
        // String bad = new String(buffer, 0, 100);

        // Safe conversion with validation
        int offset = 0;
        int length = 100;
        if (offset >= 0 && length >= 0 && offset + length <= buffer.length) {
            String safe = new String(buffer, offset, length);
        } else {
            throw new IllegalArgumentException("Invalid offset/length");
        }
    }
}

Security: Why char[] and How to Zero Out After Conversion

Java's security APIs (JPasswordField, KeyStore, Console.readPassword) return passwords as char[] instead of String for a specific reason: char arrays are mutable and can be cleared explicitly after use. String is immutable — once created, the backing array lives on the heap until garbage collected. And because String objects are interned, they can survive long after you discard the reference.

When you convert a char[] password to a String, you create an immutable copy. Even if you zero the original char[], the String still holds the password in its private array. The only way to truly clear it is to ensure the String object is garbage collected quickly — but you can't zero it.

Best practice: avoid converting char[] to String for sensitive data. If you must, null the String reference right after use and trust the GC (it's not immediate). For additional protection, use a char[] throughout the sensitive operation and only convert at the exact point that requires a String (e.g., passing to a legacy API).

package io.thecodeforge.security;

import java.util.Arrays;

public class SecurePasswordConversion {
    public static void main(String[] args) {
        char[] password = retrievePasswordFromSecureStore();

        // Only convert when absolutely necessary
        String passwordString = null;
        try {
            passwordString = new String(password);
            authenticate(passwordString);
        } finally {
            // Zero original char array
            Arrays.fill(password, '\0');
            // Nullify the String reference to help GC
            passwordString = null;
        }
    }

    private static char[] retrievePasswordFromSecureStore() {
        // Simulating a secure store
        return new char[]{'s', '3', 'c', 'r', '3', 't'};
    }

    private static void authenticate(String password) {
        System.out.println("Authenticating with: " + password);
    }
}

Performance Considerations: When Method Choice Matters

For most use cases, the performance difference between methods is negligible. All four methods ultimately copy the character data. But there are scenarios where method choice impacts memory and CPU.

For small arrays (< 1000 characters), any method works. For large arrays (millions of characters), use the direct constructor or valueOf — both make exactly one copy. StringBuilder.append makes two copies: first into its internal buffer (which may resize), then into the final String. String.copyValueOf is identical to valueOf but kept for legacy compatibility — no performance penalty.

Memory overhead: Each copy consumes 2 bytes per character (char in Java is UTF-16). A 1 million character array → 2 MB for the source + 2 MB for the String = 4 MB peak. StringBuilder adds another 2 MB during append (its buffer may be larger due to growth factor). Avoid StringBuilder for direct conversion.

Consider using the partial constructor (offset+count) when you only need a portion of the array. It avoids copying the entire input.