Java SDK: Migrate from V1 to V2
Java SDK: Migrate from V1 to V2
Java SDK: Migrate from V1 to V2
Skyflow Java SDK v2 introduces a new authentication model, multi-vault support via a builder pattern, native Java collections in place of third-party JSON objects, and richer error diagnostics. This guide walks through the key changes with before-and-after code examples, focuses on Insert end-to-end, then shows how the same pattern applies to other operations. A final section covers the v2.1+ field and method renames, which are backward compatible.
V1 required implementing a TokenProvider interface. V2 lets you choose from five credential types.
V1:
V2:
Use only one authentication method per credentials object.
V2 introduces a builder pattern and multi-vault support. Log levels are now per-instance instead of global.
V1:
V2 (single vault):
V2 (multiple vaults):
Key changes:
vaultUrl is replaced by clusterId (derived from your vault URL).env is now required. Supported values: Env.PROD, Env.SANDBOX, Env.DEV.V2 replaces JSONObject/JSONArray from third-party libraries with native HashMap and ArrayList. Requests use a builder pattern.
V1:
V2:
V1 response:
V2 response:
Every vault operation in v2 follows the same pattern: build a typed request with the request class’s builder, then pass it to the corresponding method on the vault client. The snippets below show v2 request construction.
Get:
Update:
Delete:
Detokenize:
Query:
V2 moves request options onto the request builder itself instead of a separate InsertOptions object.
V1:
V2:
The same builder-based pattern applies to UpsertRequest, UpdateRequest, DeleteRequest, and GetRequest.
V2 errors carry more context to help with debugging.
V1:
V2:
Use the requestId field when contacting Skyflow Support — it uniquely identifies the request for faster diagnosis.
v2.1.0 introduces a set of backward-compatible field and method renames. Legacy forms continue to work and emit deprecation warnings.
Credential field names:
The credentials JSON file accepts both the legacy and new key names.
Response field names:
Response maps now return skyflowId (camelCase). The legacy skyflow_id key is still present for backward compatibility but is deprecated.
Update request data key:
When calling update(), use skyflowId (camelCase) as the key in the data map to identify the record. Using skyflow_id still works but emits a deprecation warning. If both keys are present, skyflowId takes precedence.
Method renames:
The following instance methods have been renamed for consistency. The old names still work but emit deprecation warnings.
For the full list of changes, see the Java SDK releases on GitHub.
If you hit issues during migration, contact Skyflow Support and include the requestId from any failed call.