The A2A Java SDK 1.2.0.Final has shipped with hardened authorization, a new task stream lifecycle hook SPI, deep immutability for spec records, versioned documentation, and aggregated Javadoc. The release includes three breaking changes: RequestHandler.validateRequestedTask() is renamed to authorizeTaskAccess() with new parameters, several packages were renamed to resolve split-package issues, and TaskState.UNRECOGNIZED is renamed to TASK_STATE_UNSPECIFIED with its isFinal property changed from true to false. Several bug fixes address task store reconciliation, JSON-RPC serialization, streaming history length handling, and a Vert.x HTTP client race condition.
Questions this post answers
What breaking changes are in A2A Java SDK 1.2.0.Final?
Three breaking changes ship in this release: RequestHandler.validateRequestedTask() is renamed to authorizeTaskAccess() and takes additional ServerCallContext and TaskOperation parameters; several packages are renamed so no Java package spans multiple Maven modules, moving classes like CollectionCopies and Utils to org.a2aproject.sdk.spec.util; and TaskState.UNRECOGNIZED is renamed to TASK_STATE_UNSPECIFIED with isFinal() changed from true to false. Track breaking SDK changes like these on daily.dev before they slow down your next upgrade.
How do I migrate DefaultRequestHandler.create() to the new builder pattern in A2A Java SDK 1.2.0?
DefaultRequestHandler.create() is replaced by DefaultRequestHandler.builder(), which chains agentExecutor, taskStore, queueManager, pushConfigStore, mainEventBusProcessor, executor, and eventConsumerExecutor, plus two new optional settings: authorizationProvider() and populateReferredTasks(true). SimpleRequestContextBuilder also now requires a third authorizationProvider parameter, which can be passed as null if authorization is unused. Compare old and new API signatures side by side on daily.dev when planning a migration.
Why does A2A Java SDK now enforce read authorization on referenced tasks?
Previously, when a request referenced existing tasks via referenceTaskIds, the SDK populated those tasks into the RequestContext without checking read authorization, letting an unauthorized caller probe for task existence through sendStreamingMessage or subscribeToTask. Version 1.2.0.Final closes this gap across all transports (JSON-RPC, gRPC, REST) and makes InMemoryTaskStore fail-closed when authorization is configured but no call context is available. Follow security-hardening fixes like this on daily.dev to keep authorization logic airtight.