Repository navigation
[Java] Class name / file name casing mismatch for acronyms causes compilation failure #7654
Description
What are you generating using Kiota, clients or plugins?
API Client/SDK
In what context or format are you using Kiota?
Nuget tool
Client library/SDK language
Java
Describe the bug
The Java code generator produces files where the file name doesn't match the public class name inside, causing compilation to fail with:
error: class X is public, should be declared in a file named X.java
Acronyms (e.g., DLP, BI, MS365D) are likely cased inconsistently between JavaPathSegmenter.NormalizeFileName (which generates the file name) and CodeClassDeclarationWriter (which writes the class declaration). This results in 19 broken files under com.microsoft.graph.beta.models.security.
Expected behavior
The generated file name and public class name always match exactly.
How to reproduce
See microsoftgraph/msgraph-beta-sdk-java#1309 — Gradle Build, API Level Lint, and CodeQL all fail with 19 compileJava errors.
Open API description file
No response
Kiota Version
Microsoft.OpenApi.Kiota v1.31.1
Latest Kiota version known to work for scenario above?(Not required)
No response
Known Workarounds
N/A
Configuration
No response
Debug output
Click to expand log
```</details>
### Other information
Fix should normalize acronym casing on `CodeClass.Name` in `JavaRefiner.cs` or `JavaPathSegementer.cs`.
Metadata
Metadata
Type
Projects
- Status
Activity
ramsessanchez commentedon Apr 29, 2026
This turned out to be a GitHub issue where file name casing changes are not detected as modifications.
As a result, when metadata type names changed casing—for example:
the corresponding class names inside the files were updated accordingly. However, Git did not recognize the casing change at the file name level.
This leads to a mismatch during generation:
The recommended fix is to:
This issue is particularly problematic in Java, where the file name must match the class name exactly. In .NET and other languages, similar discrepancies between class names and file names can occur, but they do not cause build or compile failures.
Unfortunately, we cannot enforce casing standards for enums or types in the metadata. One potential alternative would be to normalize casing during generation, but this would introduce breaking changes across multiple v1 API descriptions.
ramsessanchez commentedon Apr 30, 2026
Closing the pull request as the solution is to instead add a check to our sdk's that prevent case changes such as that from being passed, especially in v1.0 as they present a binary breaking change.
ramsessanchez commentedon Apr 30, 2026
Keeping issue open in the meantime until this is resolved for Java Beta, and a fix is addressed in either SDK build checks or metadata validation.
ramsessanchez commentedon May 4, 2026
Created PR targeting a metadata quality check to address casing issues at the source.
microsoftgraph/msgraph-metadata#1094
ramsessanchez commentedon May 8, 2026
Metadata validation added and closed here: microsoftgraph/msgraph-metadata#1094