René's URL Explorer Experiment

Title: Consistent JSON forward/backward compatibility (2.0 foundation) by chemicL · Pull Request #927 · modelcontextprotocol/java-sdk · GitHub

Open Graph Title: Consistent JSON forward/backward compatibility (2.0 foundation) by chemicL · Pull Request #927 · modelcontextprotocol/java-sdk

X Title: Consistent JSON forward/backward compatibility (2.0 foundation) by chemicL · Pull Request #927 · modelcontextprotocol/java-sdk

Description: Motivation and Context The MCP specification evolves continuously; domain types must absorb new fields and subtypes without breaking existing clients or servers. On the 1.x line this is structurally prevented by sealed interfaces, which make it impossible to add a permitted subtype without breaking exhaustive pattern-match switch expressions in caller code. This commit opens the 2.0 release line, where those constraints are lifted and serialization is made self-contained — independent of any global ObjectMapper configuration. Breaking Changes Breaking changes for users migrating from 1.x Sealed interfaces removed from JSONRPCMessage, Request, Result, Notification, ResourceContents, CompleteReference and Content. Exhaustive switch expressions over these types must add a default branch. Prompt(name, description, null) no longer silently coerces null arguments to an empty list. Use Prompt.withDefaults() to preserve the previous behaviour. CompleteCompletion.total and .hasMore are now absent from the wire when not set, rather than being emitted as null. ServerParameters no longer carries Jackson annotations; it is an internal configuration class, not a wire type. What now works that did not before CompleteReference polymorphic dispatch (PromptReference vs ResourceReference) works through a plain readValue or convertValue call — no hand-rolled map inspection required. LoggingLevel deserialization is lenient: unknown level strings produce null instead of throwing. All domain records now tolerate unknown JSON fields, so a client built against an older SDK version will not fail when a newer server sends fields it does not yet recognise. Null optional fields are consistently absent from serialized output regardless of ObjectMapper configuration. Documentation CONTRIBUTING adds an "Evolving wire-serialized records" section: a 9-rule recipe and example for adding a field safely. MIGRATION-2.0 documents all breaking changes listed above. Follow-up coming next Several spec-required fields (e.g. JSONRPCError.code/message, ProgressNotification.progress, CreateMessageRequest.maxTokens, CallToolResult.content) are stored as nullable Java types without a null guard. If constructed with null, the NON_ABSENT rule silently omits them, producing invalid wire JSON without throwing. Fix: compact canonical constructors with Assert.notNull, following the pattern already in JSONRPCRequest. Types of changes Bug fix (non-breaking change which fixes an issue) New feature (non-breaking change which adds functionality) Breaking change (fix or feature that would cause existing functionality to change) Documentation update Checklist I have read the MCP Documentation My code follows the repository's style guidelines New and existing tests pass locally I have added appropriate error handling I have added or updated documentation as needed

Open Graph Description: Motivation and Context The MCP specification evolves continuously; domain types must absorb new fields and subtypes without breaking existing clients or servers. On the 1.x line this is structurall...

X Description: Motivation and Context The MCP specification evolves continuously; domain types must absorb new fields and subtypes without breaking existing clients or servers. On the 1.x line this is structurall...

Opengraph URL: https://github.com/modelcontextprotocol/java-sdk/pull/927

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width