Checker framework study notes

Overview

In the Caffeine source code, I saw the checkerframework as a small tool, so there is this article:

<dependency>
    <groupId>org.checkerframework</groupId>
    <artifactId>checker-qual</artifactId>
    <version>3.5.0</version>
</dependency>
<dependency>
    <groupId>org.checkerframework</groupId>
    <artifactId>checker-compat-qual</artifactId>
    <version>2.5.5</version>
</dependency>

maven-checker-framework

Introduction

The official website
GitHub
maven
The Checker Framework, CF, provides a mechanism to extend the functions of the Java compiler by writing plug-ins. Dozens of inspection rules are built-in, and inspection rules can also be easily customized. Mainly use the annotations in Java to enhance the ability of the type checking step in the compilation process.

Instance

GetStarted.java source code:

import org.checkerframework.checker.nullness.qual.*;
public class GetStarted {
    
    
    void sample() {
    
    
        @NonNull Object ref = null;
    }
}

Use javac provided by CF to compile the code you need to check during runtime. For Linux/Mac users, you can add these two lines in .bashrcor .zshrc:

export CHECKER_FRAMEWORK=${install_path}/checker-framework-2.1.9
alias javacheck='$CHECKER_FRAMEWORK/checker/bin/javac'

:
javacheck -processor org.checkerframework.checker.nullness.NullnessChecker GetStarted.java
-process org.checkerframework.checker.nullness.NullnessCheckerSpecify that the error to be detected is a null pointer. CF also comes with many other useful plug-ins to detect other types of errors.

The above command will print:

GetStarted.java:5: 错误: [assignment.type.incompatible] incompatible types in assignment.
        @NonNull Object ref = null;
                              ^
  found   : null
  required: @UnknownInitialization @NonNull Object
1 个错误

IDEA support

checker-framework-support has
not been updated for a long time.

expand

RetentionPolicy

@RetentionPolicy.SOURCE => usually used in documents
@ RetentionPocily.CLASS => allows to provide some information to the compiler, but not to the JVM (for example, code generation during compilation)
@ RetentionPolicy.RUNTIME => allowed at the JVM level (So ​​at runtime) Retrieve annotation information.

FindBugs

FindBugs is a mature bug solution with two implementations: Google Code and Source Forge . As can be seen from the following two screenshots, the dependency libraries included in the two are basically the same.
Insert picture description here
Insert picture description here
And JSR 305 is part of FindBugs.

JSR 305

JCP official website: JSR 305 ,
through the definition of annotation classes, suitable for use in the underlying general code base. GAV is as follows:

<dependency>
  <groupId>com.google.code.findbugs</groupId>
  <artifactId>jsr305</artifactId>
  <version>3.0.2</version>
</dependency>

or

<dependency>
  <groupId>net.sourceforge.findbugs</groupId>
  <artifactId>jsr305</artifactId>
  <version>1.3.7</version>
</dependency>

findbugs-and-jsr-305

JSR 308

JSR 308 , JCP specification.

checkerframework-jsr308 implements JSR308, Java 8 type annotations, allowing the type checker to perform static code analysis.

JSR 305 vs JSR 308

jsr305-vs-jsr308

I can answer your last question. They are not the same thing. 305 is about new annotations where you can already put them, which can help provide programmatic visibility into a design by contract system. So that if a certain method is supposed to not return null, or if a certain method is supposed to never receive a null parameter, it is possible to tell the system analyzing the annotations to look out for this specific case at this piece of code.

308 is about being able to annotate more things, such as a generic parameter and a type cast. I imagine a primary use for that is to be able to suppress warning on a specific type cast, instead of having to declare a local variable for that purpose. The @SuppressWarnings annotation already exists (whereas JSR-305 would look to define new ones), but in JSR-308 it could be applied to more cases.

According to this 308 will be part of Java7, which would imply it is quite well along to being stable. JSR-305 isn’t on the list, so it doesn’t look like it will make it to Java7.

Compared

Various items define their own NonNull annotations, for example:

  1. org.checkerframework.checker.nullness.qual.NonNull
  2. edu.umd.cs.findbugs.annotations.NonNull
  3. javax.annotation.Nonnull
  4. javax.validation.constraints.NotNull
  5. lombok.NonNull
  6. org.eclipse.jdt.annotation.NonNull

reference

http://shzhangji.com/cnblogs/2018/09/22/how-to-avoid-null-pointer-exception/

Guess you like

Origin blog.csdn.net/lonelymanontheway/article/details/107622927