[http-client-java] make Accept header with constant @clientDefaultValue required

[XiaofeiCao]

• fix [http-client-java] emitter support for constant optional parameter with @clientDefaultValue #10178

[github-actions]

All changed packages have been documented.

• ✅ @typespec/http-client-java

Show changes

@typespec/http-client-java - feature ✏️

Emitter support for constant optional Accept header with @clientDefaultValue. When an Accept header is optional with a constant type and has @Legacy.clientDefaultValue, the emitter now treats it as a required constant, ensuring the value is always sent and hidden from the public API.

[azure-sdk]

You can try these changes here

🛝 Playground	🌐 Website	🛝 VSCode Extension

[srnagar]

Why is this specific to "accept" header only? We should make this generic and clientDefaultValue should work the same way everywhere.

[XiaofeiCao]

This is kind like a "hack" to support Search case before we support @clientDefaultValue in general.
A bit concern from me is that we are expanding our support for @clientDefaultValue a bit too far.
Or do you think we should support @clientDefaultValue in general?

[weidongxu-microsoft]

For a normal e.g. query parameter

@query
@clientDefaultValue("instanceView")
expand?: "instanceView";

I think emitter would generate API like

Paged<> list() {
  Expand expand = Expand.INSTANCE_VIEW;
  RequestOptions requestOptions = new RequestOptions();
  if (expand != null) {
    requestOptions.addQuery("expand", expand);
  }
  return list(requestOptions);
}

Paged<> list(Expand expand) {
  RequestOptions requestOptions = new RequestOptions();
  if (expand != null) {
    requestOptions.addQuery("expand", expand);
  }
  return list(requestOptions);
}

So if user calls list((Expand) null), they can send the request without expand parameter.

---

Hence in this Accept case, we are doing special process here. Given that TCGC would always give us a generated Accept parameter (if op has response body and TypeSpec does not define the header), it seems OK for us to use the only non-null Accept value.

But this seems not applicable to other header/query param.

[srnagar]

What if this is an enum with multiple values? How do we handle clientDefaultValue in such cases or is that going to be an error?

[XiaofeiCao]

This PR only handles constant optional case, not including enum case. If it's regular enum, we will ignore @clientDefaultValue and treat it as regular property.
Another thought, do we want to also make it required in such case? Is there a real use case for it?