Skip to content

API, AWS, BigQuery, Core, Flink, Hive, Nessie, ORC, Parquet, Spark: Use Locale.ROOT instead of Locale.ENGLISH for case conversion - #17442

Open
uros-b wants to merge 2 commits into
apache:mainfrom
uros-b:core-sortorderparser-locale-root
Open

API, AWS, BigQuery, Core, Flink, Hive, Nessie, ORC, Parquet, Spark: Use Locale.ROOT instead of Locale.ENGLISH for case conversion#17442
uros-b wants to merge 2 commits into
apache:mainfrom
uros-b:core-sortorderparser-locale-root

Conversation

@uros-b

@uros-b uros-b commented Jul 30, 2026

Copy link
Copy Markdown
Member

This aligns the whole codebase on Locale.ROOT for locale-independent case conversion, which is the project convention (the checkstyle / Error Prone locale rules recommend Locale.ROOT, and the tree already used it in ~374 places versus a residual ~58 uses of Locale.ENGLISH).

This PR replaces every remaining Locale.ENGLISH with Locale.ROOT across all modules (API, AWS, BigQuery, Core,Flink, Hive, Nessie, ORC, Parquet, Spark).

Output is byte-identical: these call sites all pass an explicit locale to toUpperCase / toLowerCase over ASCII enum names and canonical tokens, and Locale.ROOT and Locale.ENGLISH produce the same result for ASCII, so there is no behavior change. The SortOrderParser change is kept as the first commit and the remaining occurrences are swept in a follow-up commit; one line in ContentFileParser is reflowed by spotless because Locale.ROOT is shorter.

The SortDirection serializer used Locale.ENGLISH while the null-order parser in the same class uses Locale.ROOT. This aligns on Locale.ROOT for locale-independent canonical output, per project convention. Output is byte-identical for the ASCII enum values.
@github-actions github-actions Bot added the core label Jul 30, 2026

@szehon-ho szehon-ho left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good — safe consistency fix.

SortDirection values are ASCII (ASC/DESC), so toLowerCase(Locale.ENGLISH) and toLowerCase(Locale.ROOT) produce identical "asc"/"desc" output. Aligns with the null-order parser in the same class and the project convention to use Locale.ROOT for case conversion. No behavioral or compatibility risk.

@vishnuprakaz vishnuprakaz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few more Locale.ENGLISH conversions in core (SnapshotRefParser, ContentFileParser, TimerResultParser, TableMetadataParser, IsolationLevel, CatalogUtil,MetricsModes, ExpressionParser, Avro).
Happy to do a follow up for those unless you were planning to.

@uros-b uros-b left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you folks, I'll push some more changes here for a more holistic / complete fix

Replace the remaining Locale.ENGLISH usages with Locale.ROOT across all modules
(api, core, aws, bigquery, flink, hive-metastore, nessie, orc, parquet, spark)
for consistency with the rest of the codebase. Output is byte-identical: these
call sites all pass an explicit locale to toUpperCase/toLowerCase over ASCII enum
names and canonical tokens, and ROOT and ENGLISH produce the same result for
ASCII. No behavior change.
@uros-b uros-b changed the title Core: Use Locale.ROOT in SortOrderParser case conversion API, AWS, BigQuery, Core, Flink, Hive, Nessie, ORC, Parquet, Spark: Use Locale.ROOT instead of Locale.ENGLISH for case conversion Jul 31, 2026

@szehon-ho szehon-ho left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. This PR only replaces the locale argument for toLowerCase/toUpperCase calls. Locale.ROOT and Locale.ENGLISH use the same Unicode case mappings, while Locale.ROOT better expresses that these protocol values, enum names, and serialized tokens are language-neutral. The change is behavior-preserving and aligns the codebase with the established convention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants