@@clientName on discriminated union subtypes is ignored — generates original TypeSpec name instead of renamed name

[yungshinlintw]

Bug Report

Emitter Version

@azure-tools/typespec-java v0.44.6

Description

@@clientName directives for discriminated union subtypes are ignored during code generation. The emitter generates classes using the original TypeSpec model name instead of the @@clientName-specified name.

This is a regression — the GA version of our SDK (generated with an earlier emitter) correctly produced ContentArrayField, ContentStringField, etc. The new emitter produces ArrayField, StringField, etc., ignoring the @@clientName directives.

Repro

TypeSpec models (models.tsp):

model ArrayField extends ContentField {
  type: ContentFieldType.array;
  valueArray?: ContentField[];
}

model StringField extends ContentField {
  type: ContentFieldType.string;
  valueString?: string;
}
// ... other subtypes

Client customization (client.tsp) — source: client.tsp L207-L215:

@@clientName(StringField, "ContentStringField", "java");
@@clientName(DateField, "ContentDateField", "java");
@@clientName(TimeField, "ContentTimeField", "java");
@@clientName(NumberField, "ContentNumberField", "java");
@@clientName(IntegerField, "ContentIntegerField", "java");
@@clientName(BooleanField, "ContentBooleanField", "java");
@@clientName(ArrayField, "ContentArrayField", "java");
@@clientName(ObjectField, "ContentObjectField", "java");
@@clientName(JsonField, "ContentJsonField", "java");

Expected Behavior

The emitter should generate Java classes with the @@clientName-specified names:

• ContentArrayField.java
• ContentStringField.java
• ContentNumberField.java
• etc.

Actual Behavior

The emitter generates classes using the original TypeSpec model names, ignoring @@clientName:

• ArrayField.java
• StringField.java
• NumberField.java
• etc.

The base class ContentField.java discriminator also references the un-renamed names (ArrayField.fromJson() instead of ContentArrayField.fromJson()).

Impact

This is a breaking change for our published GA SDK (azure-ai-contentunderstanding). Our GA SDK exposes ContentArrayField, ContentStringField, etc. as public types that customers import and use with instanceof checks. Regenerating with the new emitter would rename these types, breaking all existing consumer code.

Our customization file (ContentUnderstandingCustomizations.java) also references these types by their @@clientName names and fails with:

java.lang.IllegalArgumentException: ContentArrayField does not exist in package com.azure.ai.contentunderstanding.models

Merged GA SDK (proof that older emitter correctly applied @@clientName)

• Java GA SDK PR: Content Understanding GA SDK for Java — merged 2026-03-02
  • Generated class (correct name): ContentArrayField.java
  • Customization referencing these types: ContentUnderstandingCustomizations.java

Context

• TypeSpec @@clientName directives: client.tsp L207-L215 (Java) and client.tsp L166-L174 (C#)
• TypeSpec repo: azure-rest-api-specs-pr (private), PR #27815
• SDK: azure-ai-contentunderstanding
• API version: 2026-07-01-preview (base GA: 2025-11-01)
• The same issue also affects the C# emitter (@azure-typespec/http-client-csharp) — microsoft/typespec#10657

[yungshinlintw]

Related C# emitter issue: microsoft/typespec#10657 — same symptom in the C# emitter (@azure-typespec/http-client-csharp). Possibly a shared root cause in TCGC (@azure-tools/typespec-client-generator-core).

[yungshinlintw]

Additional Context — TypeSpec source and merged GA SDK

TypeSpec @@clientName directives (public GA spec, merged):

• C# renames: client.tsp L166-L174
• Java renames: client.tsp L207-L215

These @@clientName directives were respected by the previous emitter version and the GA SDK was published with ContentArrayField, ContentStringField, etc. as public types.

Merged GA SDK PR (proof that the older emitter correctly applied @@clientName):

• Java GA SDK: Content Understanding GA SDK for Java — merged 2026-03-02
  • Example generated class: ContentArrayField.java
  • Customization referencing these types: ContentUnderstandingCustomizations.java

The new emitter (v0.44.6) generates ArrayField.java instead of ContentArrayField.java for the exact same TypeSpec input.

[weidongxu-microsoft]

@yungshinlintw

How do you call the emitter to generate code?

0.44.6 is in the emitter in current SDK repo. There is no prior emitter at work.
Whenever we merge a new emitter version into SDK repo, we re-generate all SDKs with it, include this contentunderstanding SDK.

When I run tsp-client update in sdk/contentunderstanding/azure-ai-contentunderstanding folder, it generates code fine. And there is no diff with your existing code there.