0

I am trying to understand how Checker Framework implements Pluggable Type Checkers. By reading the documentation,

Checker Framework (Maven)

I see a lot of setup involved, and looks to me either outdated or not quite mantained.

As far as I read, Java 8 supported both Type Annotations and Pluggable Type Checkers on JSR-308 and JSR-269 , allowing an interface to create custom annotations on almost every element, and process it with a snippet of interfaced code with a simple flag on javac (-processor), which maven supports through META-INF/services/javax.annotation.processing.Processor

Then why documentation states that Checker requires that many customization..?:

  - com.google.errorprone.javac "error-prone" jdk if javac should support custom annotation processors (JSR-269)?
  - maven dependency plugin
  - mvn compiler plugin with annotationProcessorPaths (which I understand it overrides anything from the META-INF file) instead of `META-INF/services/javax.annotation.processing.Processor`

I presume Checker framework has remained effectively a collection of custom annotation processors since Java 8 feature. Is it like that? It does not seem needed anymore to enable the compiler, to create custom checkings (JSR-269) and to enable /* @Nullable */ and the like... I'll be happy to stand corrected

Whimusical
  • 6,401
  • 11
  • 62
  • 105

1 Answers1

1

I see a lot of setup involved, and looks to me either outdated or not quite mantained.

What, specifically, looks outdated or "not quite maintained"? What is your evidence? If you just make unsubstantiated assertions, the community cannot help you.

As far as I read, Java 8 supported both Type Annotations and Pluggable Type Checkers on JSR-308 and JSR-269

Your reading is incorrect. JSR 308 supports Type Annotations, but JSR 269 does not support Pluggable Type Checkers. You need a third-party tool such as the Checker Framework to perform pluggable type-checking.

Can you point out the specific text that led you to this conclusion? Specifics would be helpful rather than just an assertion without support.

to enable /* @Nullable */

Support for annotations in comments was ended 20 months ago. Can you point out the text that led you to your question about annotations in comments?

mernst
  • 7,437
  • 30
  • 45
  • Hi mernst! I said "looks to me", I had the feeling because of my wrong assumptions that all of this was not needed anymore. If you really need the checker framework for the pluggable type-checking then everything makes sense. But just by reading (sorry cannot tell you the sites, read a lot on the topic) I assumed that you could just drop the annotation processor on the META-INF on a maven project, without any special frameworkm and javac supported. Why exactly is needed the third-party tool besides the annotation processors code? – Whimusical Dec 18 '19 at 23:32
  • I mean doesnt built-in javac suport -processor flag and meta-inf/processors mechanism? – Whimusical Dec 19 '19 at 01:13
  • 1
    Java provides an annotation processing interface (invoked via `-processor`) that visits declaration annotations on packages, fields, and methods. Such an annotation processor cannot examine the source code nor annotations in the source code. The Checker Framework is an annotation processor that provides a visitor for the entire source code, so it can be used for pluggable type-checking. (All this is orthogonal to processor auto-discovery or Maven invocation, which works the same for any annotation processor.) – mernst Dec 23 '19 at 16:56
  • Thanks! But still I have some doubts. In this example, https://www.baeldung.com/java-annotation-processing-builder, custom annotation in the source code it's well processed. Besides, if Checker it's eventually an annotation processor under the processor interface and the META-INF mechanism is orthogonal, why are com.google.errorprone.javac and mvn compiler plugin with annotationProcessorPaths needed? – Whimusical Dec 28 '19 at 12:27
  • *Pluggable typechecking* requires traversing the AST. Simpler types of annotation processing do not. The Checker Framework manual explains the need for the com.google.errorprone.javac artifact. I suggest accepting this answer and opening new, focused questions that ask only one question. An example of a focused question is "Why is the com.google.errorprone.javac artifact needed?", and you could ask a different question for each other aspect of the setup that you do not understand. This comment thread is not a good place to explain every detail of the Checker Framework implementation. :-) – mernst Dec 28 '19 at 17:30
  • You are absolutely right, I cannot thank you enough mernst! – Whimusical Dec 28 '19 at 20:36
  • 1
    No problem, that's what Stack Overflow is for. – mernst Dec 28 '19 at 23:29