Treat a single upper case letter as a type name in a dotted chain - #70
Merged
Merged
Conversation
A dotted name is broken after its type-name prefix, and the prefix is found from the case of each segment: "com.example.Foo.bar" is a package, a class and a member. A single upper case letter such as Android's R counted as an all-caps constant, so in "com.some.extremely.verbose.pkg.name.R.string.some_resource" no prefix was found and the name broke at every dot, one segment per line. This ports google/google-java-format#731 by Liam Miller-Cushon: a single upper case letter is UpperCamelCase, so the chain keeps "com.some.extremely.verbose.pkg.name.R.string" together and breaks before the last segment. The golden b26306390 and the two TypeNameClassifierTest assertions come from upstream, with the expected output in this project's style. The 15,747 files of the JDK 21 sources format exactly as before.
abashev
added a commit
to openjavaformat/docs
that referenced
this pull request
Sep 25, 2026
…ange 2.98.0.4 carries two more fixes that change code palantir-java-format 2.98.0 has already formatted: a one-letter class name such as Android's R no longer counts as a constant in a dotted name (openjavaformat/open-java-format#70), and tabs at the end of a line in a comment are dropped (openjavaformat/open-java-format#73). Neither shows on the JDK 21 sources, which have no such dotted name and no comment ending in a tab, and the corpus paragraph now says so. The other fixes of 2.98.0.4 leave code that palantir-java-format has already formatted as it is, so they stay off the list. Every item now links the pull request behind it. The string fix went to main without one, so it links the issue it closed, openjavaformat/open-java-format#32. The GitHub Action page gives 2.98.0.4 as the default of the version input, as the action's main branch now does (openjavaformat/open-java-format-action@83d0df8).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings over google/google-java-format#731, a fix from google-java-format 1.14.
The bug
A dotted name is broken after its type-name prefix, and the prefix is found from the case of each segment:
com.example.Foo.baris a package, a class and a member. A single upper case letter such as Android'sRcounted as an all-caps constant, so a long resource reference found no prefix and broke at every dot:From upstream, with the author kept
TypeNameClassifier, so the chain keepscom.some.extremely.verbose.pkg.name.R.stringtogether and breaks once, before the last segment. The upstream goldenb26306390and the twoTypeNameClassifierTestassertions come with it, with the expected output in this project's style.Checked
from("A")assertion fail on main and pass with the change../gradlew :open-java-format:teston JDK 21: 1501 tests, all green.