Restore the -Xlint category on in-process javac warnings - #515
Merged
Merged
Conversation
javac prints [deprecation] and friends only in Diagnostic.toString(); getMessage() leaves it out and getCode() never carried it, so the category is read back off the rendering. Do not simplify that to getMessage() again: the forked compiler keeps the category because it parses javac's output, and the two back-ends have to agree.
slachiewicz
added
bug
slachiewicz
marked this pull request as ready for review
September 9, 2026 11:44
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
1 participant
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.
Warnings compiled in process lost the bracketed lint category javac prints in front of them, so
[deprecation]or[module]never reached the build log and the reader had no way to tell which-Xlint:flag or@SuppressWarningskey would silence the warning. Fixes #183.This is a back-end parity defect rather than a JDK limitation. The forked compiler already keeps the category because it parses javac's own output —
ErrorMessageParserTestpins[deprecation] ThreadSafeClientConnManager …— which is why<forceJavacCompilerUse>true</forceJavacCompilerUse>was the workaround given on the issue. Only thejavax.toolspath drops it.Diagnostic.getMessage(Locale)omits the category by design (JDK-8292634, closed as not an issue), andgetCode()carries a resource key such ascompiler.warn.raw.class.usethat does not map onto a lint category.toString()is the only place it survives, solintCategoryOfreads it back from there.The category is located by anchoring on the message text rather than on the
warning:marker in front of it: the marker is localised (警告:[deprecation], as in the existing parser tests) while the category never is. Only the first line of the message is used as the anchor, because a wrapped message continues below the source line and caret and is not contiguous in the rendering. A bracket that merely sits in a path is rejected — it has to be the last thing before the message and a single token.The
missing-warningsIT is the reporter's own case, but it setsforceJavacCompilerUse, which is exactly why it passed while the bug was open. Amissing-warnings-in-processsibling now covers the default path; without the change it fails with the symptom from the issue,module-info.java:[2,32] module not found: someOtherModule.Not addressed here: forked and in-process message bodies still differ where javac abbreviates a type in its console output (
found raw type: List) that the API spells out (found raw type: java.util.List). The new unit test compares the category and the line, not the body.Verified:
mvn installon JDK 25, whole reactor green, 12 ITs pass; reverting the prepend inJavaxToolsCompilerfails the new IT and the new parity test.This change was created with AI assistance.