quarkus-core: runtimeannotations

[Pankraz76]

unused files in src/main/java/io/quarkus/runtime

This works on my machine, indicating it might be unused as well.

Is this a leftover, considered obsolete at the moment, or intended for future usage?

Directory: quarkus-core

Path: src/main/java/io/quarkus/runtime

Subdirectory: annotations

• ConfigDocEnum.java
• ConfigDocFilename.java

Configuration Files:

• BuildAnalyticsConfig.java
• BuilderConfig.java
• CommandLineRuntimeConfig.java
• DebugRuntimeConfig.java

---

Reference Image

Implementation ideas

No response

[maxandersen]

I looked these up and all are either enums which are read dynamically or config classes for the configuration system which document the values for configuration thus things might build but break users apps.

[Pankraz76]

might build

should simply test, even with AI, to prevent this from happening again.

Having to look up seems more effort then c&p simple test.

Thanks for update.

[maxandersen]

I honestly cannot understand what you are referring to.

Are you saying that it would be good to have a test for these ? Sure. A pr that has a test showing these and verify their real use makes sense.

Feel free to submit such.

But do note some of them has javadoc explaining what they exist for.

[Pankraz76]

break users apps

this situation should ideal be covered by some test, to prevent merge.

things might build but break users apps

this should ideally exclude each other, considering this the motivation behind QA.

[Pankraz76]

This clearly demonstrates a strategic issue rather than a tactical one, as observed in other cases.

Only automated systems can reliably enforce quality gates. We’ve already learned this lesson the hard way—when Quarkus’s own whitespace handling led to reimplementing Spotless functionality, yet still failed to properly address the issue, leaving unneeded imports in the codebase despite attempts to block them.

Given that none of the existing tools alone can handle even this simple task, we must reinforce the principle: it’s better to have excessive safeguards than insufficient ones. Otherwise, we risk the broken window effect—small issues leading to systemic degradation.

For reference, see these related fixes and discussions:

• [S1161] Enable PMD check MissingOverride apache/maven#2403
• [S1161] Add missing @Override to overriding and implementing methods apache/maven#2402
• [S1161] use staticanalysis.MissingOverrideAnnotation to avoid missing @Override on overriding and implementing methods #48344
• [S1161] chore: Add missing @Override to overriding and implementing methods apache/maven#2446
• [S1161] use PMD to avoid missing @Override on overriding and implementing methods #48392
• https://sonarsource.github.io/rspec/#/rspec/S1161
• https://docs.openrewrite.org/recipes/staticanalysis/missingoverrideannotation
• https://pmd.github.io/pmd/pmd_rules_java_bestpractices.html#missingoverride

Its only one commit to fix one to apply the plugin, to avoid any further.

Its like starting without the goal to finish

Fixing it without introducing plugin, to prevent any further.

As rewrite is dead, it seems PMD to be the last man standing.

[maxandersen]

@Pankraz76 — we’ve read your comments, but we need to be clear: this kind of communication is not helping.

We understand your intent is to raise concerns about code quality and suggest improvements. However, repeating the same point across multiple threads with increasingly dogmatic arguments and scattered links is not constructive.

We’ve already explained:

• We value code quality, but not at the cost of maintainability and contributor burnout.
• We evaluate and introduce tooling deliberately, based on overall project needs and team consensus — not single-issue pressure.
• Enforcing 100% conformance to individual preferences (e.g., @Override everywhere or spotless enforcement) is not our current priority and flooding threads with this topic will not change that.

Please stop reiterating the same arguments.

If you have new, actionable suggestions backed by a concrete plan that considers the project’s constraints, open a well-structured issue — once. But this constant stream of fragmented posts and “just one commit” suggestions is noise, not signal.

Thanks.