Enable LexicographicalAnnotationListing

[Pankraz76]

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[sormuras]

In general, I am not opposed to sort elements by name. But seeing @Retention and @Target split apart, with for example @SuppressWarning in between, is ... odd. In book, they belong together. Logically.

I also like @API being the closest to the actual type declaration.

[Pankraz76]

Yes, it's subjective. At least there would be a clear order, some starting with JSON would then be grouped, but it's up to the community to decide each rule.

Checkstyle has both in place, so it's only somebody's darling.

• https://github.com/checkstyle/checkstyle/blob/master/pom.xml#L257

Also, this seems to be the last of the fixable rules somehow all others not apply here.

• Constant naming Pankraz76/junit5#11

Will update then as rejected.

Thanks.

[sbrannen]

I will not accept any automated sorting of annotations.

We intentionally group them logically.

Furthermore, annotation declaration matters and is retained in the byte code, and that is guaranteed in the JLS.

Granted, the order of the annotations modified in this PR may not matter in terms of semantics, but annotation order in general can matter for certain use cases.

@Pankraz76, it would be beneficial if you would first ask if the team desires such changes before spending time implementing something that may get rejected. If I recall correctly, we have told you this before, but you seem to ignore the advice for some reason.

[Pankraz76]

@Pankraz76, it would be beneficial if you would first ask if the team desires such changes before spending time implementing something that may get rejected. If I recall correctly, we have told you this before, but you seem to ignore the advice for some reason.

Yes im sorry, please excuse the amount of notifications.

We have considered to evaluate the remaining checks.

• Add error-prone.picnic.tech featuring RedundantStringConversion #5006 (comment)

I will slow down, as the interesting ones like ConstantNaming does not work apply the patch here currently.