Never use String#getBytes() in the production code (#9487)

Summary:
There are encodings that are not ASCII-compatible (like cp1140), so it is possible that a JVM is run with a default encoding in which String#getBytes() would return unexpected values even for ASCII strings.

A little bit of context: https://stackoverflow.com/questions/70913929/can-an-encoding-incompatible-with-ascii-encoding-be-set-as-a-default-encoding-in/70914154

Pull Request resolved: https://github.com/facebook/rocksdb/pull/9487

Reviewed By: riversand963

Differential Revision: D34097728

fbshipit-source-id: afd654ecaf20f6d30d9fc20c6a090398de2585eb
This commit is contained in:
Roman Puchkovskiy 2022-05-06 16:22:15 -07:00 committed by Facebook GitHub Bot
parent 736a7b5433
commit 00889cf8f2
1 changed files with 3 additions and 1 deletions

View File

@ -14,6 +14,8 @@ import java.util.Map;
import java.util.concurrent.atomic.AtomicReference;
import org.rocksdb.util.Environment;
import static java.nio.charset.StandardCharsets.UTF_8;
/**
* A RocksDB is a persistent ordered map from keys to values. It is safe for
* concurrent access from multiple threads without any external synchronization.
@ -21,7 +23,7 @@ import org.rocksdb.util.Environment;
* indicates sth wrong at the RocksDB library side and the call failed.
*/
public class RocksDB extends RocksObject {
public static final byte[] DEFAULT_COLUMN_FAMILY = "default".getBytes();
public static final byte[] DEFAULT_COLUMN_FAMILY = "default".getBytes(UTF_8);
public static final int NOT_FOUND = -1;
private enum LibraryState {