What causes "Cannot parse 64-bits double value from "%s"" in apache/cassandra?

Normalize the string: replace decimal comma with dot, trim whitespace, strip trailing f/F/d/D suffixes.

apache/cassandra · error · InvalidTypeException

Cannot parse 64-bits double value from "%s"

Error message

Cannot parse 64-bits double value from "%s"

What it means

The double codec's parse() delegates to Double.parseDouble; strings that are not valid Java/CQL double literals (NaN and Infinity accepted by Java) raise NumberFormatException, rethrown as InvalidTypeException with this message. It covers 64-bit IEEE-754 'double' column values only.

Source

Thrown at src/java/org/apache/cassandra/cql3/functions/types/TypeCodec.java:1385

        @Override
        public int serializedSize()
        {
            return 8;
        }

        @Override
        public Double parse(String value)
        {
            try
            {
                return value == null || value.isEmpty() || value.equalsIgnoreCase("NULL")
                       ? null
                       : Double.parseDouble(value);
            }
            catch (NumberFormatException e)
            {
                throw new InvalidTypeException(
                String.format("Cannot parse 64-bits double value from \"%s\"", value));
            }
        }

        @Override
        public String format(Double value)
        {
            if (value == null) return "NULL";
            return Double.toString(value);
        }

        @Override
        public ByteBuffer serializeNoBoxing(double value, ProtocolVersion protocolVersion)
        {
            ByteBuffer bb = ByteBuffer.allocate(8);
            bb.putDouble(0, value);
            return bb;
        }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Normalize the string: replace decimal comma with dot, trim whitespace, strip trailing f/F/d/D suffixes.
Use a Locale-aware NumberFormat for localized input and pass format.parse(s).doubleValue() results via codec.format instead.
Validate with a regex like ^[+-]?(\d+(\.\d*)?|\.\d+)([eE][+-]?\d+)?$ before parsing.

Example fix

// before
doubleCodec.parse("1,5"); // throws (NumberFormatException)
// after
doubleCodec.parse("1,5".replace(',', '.')); // parses 1.5

Defensive patterns

Strategy: validation

Validate before calling

static boolean isCqlDoubleLiteral(String v) {
    return v != null && v.trim().matches("^[+-]?(\\d+(\\.\\d*)?|\\.\\d+)([eE][+-]?\\d+)?$|^NaN$|^[+-]?Infinity$");
}

Type guard

boolean isDoubleLiteral(String v) {
    if (v == null) return false;
    try { Double.parseDouble(v.trim()); return true; } catch (NumberFormatException e) { return false; }
}

Try / catch

try {
    return doubleCodec.parse(raw);
} catch (InvalidTypeException e) {
    throw new IllegalArgumentException("Not a valid double literal: " + raw, e);
}

Prevention

Replace locale decimal commas with dots and strip trailing f/d suffixes before parsing.
Use NumberFormat with the correct Locale when input is user/localized, then pass double values via codec.format().
Pre-validate with Double.parseDouble in a guarded helper before invoking the codec.

When it happens

Trigger: Calling doubleCodec.parse(value) with strings like "1,5", "1.2.3", "1.5f" (trailing type suffix), "1e" (incomplete exponent), currency-formatted values, or arbitrary text.

Common situations: Locale-formatted numbers using comma as decimal separator; float literals copied from Java/C# source carrying an f/F suffix; truncated exponent notation; CSV cells containing text in a numeric column.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/978dfdb711393020. Report an issue: GitHub.