René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Un-deprecate/add no-arg builders","articleBody":"#928 deprecated no-arg builders for schema types, e.g. McpSchema.Resource\n\nI'd like you to consider reversing that decision, and also to add no-arg versions for types without them (e.g. ProgressNotification).\n\nI understand the motivation that builders not be left in an invalid state. It's worth noting that it might achieve that aim currently (I didn't audit all the classes), but if the schema ever has any fields which are mutually exclusive or conditionally required, then using constructors will only offer partial protection.\n\nThe problem is that it makes it undermines one of the main advantages of the builder pattern, which is to make construction clearer.\n\nHere was my attempt to write a CreateMessageRequest with only required properties:\n\n```java\nvar request = McpSchema.CreateMessageRequest.builder(\n        List.of(McpSchema.SamplingMessage.builder(\n            McpSchema.Role.USER,\n            McpSchema.TextContent.builder(\"Test Sampling Message\").build()).build()\n        ),\n        50\n    )\n    .build();\n```\n\nMaybe there's a better way to format/indent this, but I tried several variations and I thought this was the best one. \n\nCompare that with the same thing constructed with named properties\n\n```java\nvar request = McpSchema.CreateMessageRequest.builder()\n    .messages(List.of(\n        McpSchema.SamplingMessage.builder()\n            .role(McpSchema.Role.USER)\n            .content(McpSchema.TextContent.builder(\"Test Sampling Message\").build())\n            .build()\n    ))\n    .maxTokens(50)\n    .build();\n```\n\nIt's also worth noting that some builders have APIs like `ModelPreferences#addHint`. If that pattern were applied consistently, it could be simplified a little more by replacing `messages(List.of(` with `addMessage(`\n\n## Beyond readability\n\nI'm writing a framework and builders enforcing all required params at once makes them inflexible for some possible API designs. \n\nFor example, my framework automatically manages progress tokens. I considered a design such as\n\n```java\nvoid sendProgress(Consumer\u003cMcpSchema.ProgressNotification.Builder\u003e consumer);\n\n// an example caller. mcp creates the builder and applies the token\nmcp.sendProgress(p -\u003e p.progress(5).total(10));\n```\n\nHowever, it's not possible for the framework to implement this with the current builder methods. The user of the framework knows the progress value, the framework itself knows the progress token, but the builder expects both at once.\n\nSo the builder has to be worked around, for example to this\n\n```java\nvoid sendProgress(double progress, Consumer\u003cMcpSchema.ProgressNotification.Builder\u003e consumer);\n// an example caller\nmcp.sendProgress(5, p -\u003e p.total(10));\n```","author":{"url":"https://github.com/michaelboyles","@type":"Person","name":"michaelboyles"},"datePublished":"2026-07-18T02:11:26.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/1065/java-sdk/issues/1065"}