Feature Request: Option to generate max overloads (`WithResponse` methods) with models

[srnagar]

Clear and concise description of the problem

We should have an option to generate the max overloads (WithResponse methods) with models instead of BinaryData. We should have support for generating with just models, just BinaryData or both.

In tspconfig.yaml:

"@azure-tools/typespec-java":
  namespace: "com.azure.sample.library"
  partial-update: true
  flavor: azure
  max-overload: all

The above config should generate the following two methods:

public Response<BinaryData> createFooWithResponse(BinaryData createFooOptions, RequestOptions requestOptions); // protocol method 

public Response<FooDetails> createFooWithResponse(CreateFooOptions createFooOptions, RequestOptions requestOptions); // max overload with models

The other values for max-overload config would be protocol or model.

For scenarios where we can only support protocol methods (like patch or MFD), we ignore this flag and generate only protocol methods.

When the config is set to all and the WithResponse overloads for protocol and model differs only in the return type (i.e. the input params are identical and therefore cannot have overloads based on just return type), then we fall back to protocol method (existing behavior).

Checklist

• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[github-actions]

🎯 Issue Triage

Feature request to add a max-overload configuration option to the Java client emitter, allowing generation of WithResponse methods using strongly-typed models (in addition to or instead of BinaryData).

Category: Feature Request
Area: emitter:client:java

🔍 Analysis

• Requests a new max-overload config key in tspconfig.yaml for @azure-tools/typespec-java with three values: all, protocol, model
• all generates both protocol (BinaryData-based) and model-based WithResponse overloads
• protocol retains current behavior (only BinaryData)
• model generates only the strongly-typed model variant
• Edge cases are described: patch/MFD scenarios always fall back to protocol-only; when both overloads would have identical signatures (differing only in return type), fall back to protocol method
• No existing duplicate found

📝 Suggested next steps

• Design the max-overload config option and its allowed values in the emitter schema
• Implement code generation logic to emit model-typed WithResponse overloads when configured
• Handle fallback logic for patch/MFD and ambiguous-overload scenarios
• Add tests covering all three config values and the described edge cases

Generated by Agentic Triage

[weidongxu-microsoft]

We will go model first.

all likely will suffer from problem of method overload with exactly same method signature. E.g.

Response<BinaryData> getFooWithResponse(ReqeustOptions);
Response<ResponseModel> getFooWithResponse(ReqeustOptions);