| \htmlhr |
| \chapterAndLabel{Troubleshooting, getting help, and contributing}{troubleshooting} |
| |
| \begin{sloppypar} |
| The manual might already answer your question, so first please look for |
| your answer in the manual, |
| including this chapter and the FAQ (Chapter~\ref{faq}). |
| If not, you can use the mailing list, |
| \code{checker-framework-discuss@googlegroups.com}, to ask other users for |
| help. For archives and to subscribe, see \url{https://groups.google.com/forum/#!forum/checker-framework-discuss}. |
| To report bugs, please see Section~\ref{reporting-bugs}. |
| If you want to help out, you can give feedback (including on the |
| documentation), choose a bug and fix it, or select a |
| project from the ideas list at |
| \url{https://rawgit.com/typetools/checker-framework/master/docs/developer/gsoc-ideas.html}. |
| \end{sloppypar} |
| |
| |
| \sectionAndLabel{Common problems and solutions}{common-problems} |
| |
| \begin{itemize} |
| \item |
| To verify that you are using the compiler you think you are, you can add |
| \code{-version} to the command line. For instance, instead of running |
| \code{javac -g MyFile.java}, you can run \code{javac \underline{-version} -g |
| MyFile.java}. Then, javac will print out its version number in addition |
| to doing its normal processing. Note that if you are running under Java 8, |
| \<\$CHECKERFRAMEWORK/bin/javac -version> prints ``javac (version info |
| not available)'' because it uses the Error Prone compiler which does not |
| provide version information. |
| |
| \end{itemize} |
| |
| |
| \subsectionAndLabel{Unable to compile the Checker Framework}{common-problems-compiling} |
| |
| If you get the following error while compiling the Checker Framework itself: |
| |
| %BEGIN LATEX |
| \begin{smaller} |
| %END LATEX |
| \begin{Verbatim} |
| checker-framework/stubparser/dist/stubparser.jar(org/checkerframework/stubparser/ast/CompilationUnit.class): |
| warning: [classfile] Signature attribute introduced in version 49.0 class files is ignored in version 46.0 class files |
| \end{Verbatim} |
| %BEGIN LATEX |
| \end{smaller} |
| %END LATEX |
| |
| \noindent |
| and you have used Eclipse to compile the Checker Framework, then probably |
| you are using a very old version of Eclipse. (If you |
| install Eclipse from the Ubuntu 16.04 repository, you get Eclipse version |
| 3.8. Ubuntu 16.04 was released in April 2016, and Eclipse 3.8 was released |
| in June 2012, with subsequent major releases in June 2013, June 2014, and |
| June 2015.) |
| Install the latest version of Eclipse and use it instead. |
| |
| |
| \subsectionAndLabel{Unable to run the checker, or checker crashes}{common-problems-running} |
| |
| If you are unable to run the checker, or if the checker or the compiler |
| terminates with an error, then the problem may be a problem with your environment. |
| (If the checker or the compiler crashes, that is a bug in the Checker |
| Framework; please report it. See Section~\ref{reporting-bugs}.) |
| This section describes some possible problems and solutions. |
| |
| \begin{itemize} |
| \item |
| \label{no-such-field-error-release} |
| An error that includes \<java.lang.NoSuchFieldError: RELEASE"> means that |
| you are not using the correct compiler (you are not using a Java 9+ compiler). |
| |
| \item |
| If you get the error |
| |
| %BEGIN LATEX |
| \begin{smaller} |
| %END LATEX |
| \begin{Verbatim} |
| com.sun.tools.javac.code.Symbol$CompletionFailure: class file for com.sun.source.tree.Tree not found |
| \end{Verbatim} |
| %BEGIN LATEX |
| \end{smaller} |
| %END LATEX |
| |
| \noindent |
| then you are using the source installation and file \code{tools.jar} is not |
| on your classpath. See the installation instructions |
| (Section~\ref{installation}). |
| |
| \item |
| If you get an error like one of the following, |
| |
| %BEGIN LATEX |
| \begin{smaller} |
| %END LATEX |
| \begin{Verbatim} |
| ...\build.xml:59: Error running ${env.CHECKERFRAMEWORK}\checker\bin\javac.bat compiler |
| \end{Verbatim} |
| |
| \begin{Verbatim} |
| .../bin/javac: Command not found |
| \end{Verbatim} |
| |
| \begin{Verbatim} |
| error: Annotation processor 'org.checkerframework.checker.signedness.SignednessChecker' not found |
| \end{Verbatim} |
| %BEGIN LATEX |
| \end{smaller} |
| %END LATEX |
| |
| \noindent |
| then the problem may be that you have not set the \code{CHECKERFRAMEWORK} environment |
| variable, as described in Section~\ref{javac-wrapper}. Or, maybe |
| you made it a user variable instead of a system variable. |
| |
| \item |
| If you get one of these errors: |
| |
| \begin{alltt} |
| The hierarchy of the type \emph{ClassName} is inconsistent |
| |
| The type com.sun.source.util.AbstractTypeProcessor cannot be resolved. |
| It is indirectly referenced from required .class files |
| \end{alltt} |
| |
| \begin{sloppypar} |
| \noindent |
| then you are likely \textbf{not} using the Checker Framework compiler. Use |
| either \code{\$CHECKERFRAMEWORK/checker/bin/javac} or one of the alternatives |
| described in Section~\ref{javac-wrapper}. |
| \end{sloppypar} |
| |
| \item |
| If you get the error |
| |
| \begin{Verbatim} |
| java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy |
| \end{Verbatim} |
| |
| \noindent |
| % I'm not 100% sure of the following explanation and solution. |
| then an annotation is not present at run time that was present at compile |
| time. For example, maybe when you compiled the code, the \<@Nullable> |
| annotation was available, but it was not available at run time. |
| |
| \item |
| If you get an error that contains lines like these: |
| |
| \begin{Verbatim} |
| Caused by: java.util.zip.ZipException: error in opening zip file |
| at java.util.zip.ZipFile.open(Native Method) |
| at java.util.zip.ZipFile.<init>(ZipFile.java:131) |
| \end{Verbatim} |
| |
| \noindent |
| then one possibility is that you have installed the Checker Framework in a |
| directory that contains special characters that Java's ZipFile |
| implementation cannot handle. For instance, if the directory name contains |
| ``\<+>'', then Java 1.6 throws a ZipException, and Java 1.7 throws a |
| FileNotFoundException and prints out the directory name with ``\<+>'' |
| replaced by blanks. |
| |
| \item |
| The Checker Framework sometimes runs out of memory when processing very |
| large Java files, or files with very large methods. |
| |
| If you get an error such as |
| \begin{Verbatim} |
| error: SourceChecker.typeProcess: unexpected Throwable (OutOfMemoryError) while processing ... |
| ; message: GC overhead limit exceeded |
| \end{Verbatim} |
| |
| \noindent |
| (all on one line), |
| then either give the JVM more memory when running the Checker Framework, or |
| split your files and methods into smaller ones, or both. |
| |
| \item |
| Versions of \ahref{https://errorprone.info/}{Error Prone} before 2.4.0 are |
| incompatible with the Checker Framework. Those versions of Error Prone |
| use an outdated version of the Checker Framework's dataflow analysis |
| library, which conflicts with the Checker Framework itself. |
| |
| If you wish to use both Error Prone and the Checker Framework, then use |
| Error Prone version 2.4.0 or later. |
| If you cannot upgrade to Error Prone 2.4.0 or later, there is a way to |
| still use both tools. The |
| \ahreforurl{https://github.com/kelloggm/checkerframework-gradle-plugin\#incompatibility-with-error-prone}{Gradle |
| plugin documentation} shows how to do so if you use the Gradle build |
| system. |
| |
| \end{itemize} |
| |
| |
| \subsectionAndLabel{Unexpected warnings not related to type-checking}{common-problems-non-typechecking} |
| |
| This section gives solutions for some warning messages that are not related |
| to type errors in your code. |
| |
| \begin{itemize} |
| |
| \item |
| If you get an error like the following |
| |
| \begin{Verbatim} |
| error: scoping construct for static nested type cannot be annotated |
| error: scoping construct cannot be annotated with type-use annotation |
| \end{Verbatim} |
| |
| \noindent |
| then you have probably written something like one of the following: |
| \begin{description} |
| \item[\<@Nullable java.util.List>] |
| The correct Java syntax to write an annotation on a fully-qualified type |
| name is to put the annotation on the simple name part, as in |
| \<java.util.@Nullable List>. But, it's usually |
| better to add \<import java.util.List> to your source file, so that you can |
| just write \<@Nullable List>. |
| \item[\<@Nullable Map.Entry>] You must write \<Outer.@Nullable |
| StaticNestedClass> rather than \<@Nullable Outer.StaticNestedClass>. |
| Since a static nested class does not depend on its outer class, the |
| annotation on the outer class would have no effect and is forbidden. |
| \end{description} |
| |
| Java 8 requires that a type qualifier be written directly on the type that |
| it qualifies, rather than on a scoping mechanism that assists in resolving |
| the name. Examples of scoping mechanisms are package names and outer |
| classes of static nested classes. |
| |
| The reason for the Java 8 syntax is to avoid syntactic irregularity. When |
| writing a member nested class (also known as an inner class), it is |
| possible to write annotations on both the outer and the inner class: \<@A1 |
| Outer. @A2 Inner>. Therefore, when writing a static nested class, the |
| annotations should go on the same place: \<Outer. @A3 StaticNested> (rather |
| than \<@ConfusingAnnotation Outer.\ Nested> where |
| \<@ConfusingAnnotation> applies to \<Outer> if \<Nested> is a member class |
| and applies to \<Nested> if \<Nested> is a static class). It's not legal |
| to write an annotation on the outer class of a static nested class, because |
| neither annotations nor instantiations of the outer class affect the static |
| nested class. |
| |
| Similar arguments apply when annotating \<pakkage.Outer.Nested>. |
| |
| \item |
| An ``error: package ... does not exist'' or ``error: cannot find symbol'' |
| about classes in your own project or its dependencies means that you have |
| left your own project or its dependencies off the classpath when you |
| invoked the compiler. |
| |
| \end{itemize} |
| |
| |
| \subsectionAndLabel{Unexpected type-checking results}{common-problems-typechecking} |
| |
| This section describes possible problems that can lead the type-checker to |
| give unexpected results. |
| |
| |
| \begin{itemize} |
| \item |
| If the Checker Framework is unable to verify a property that you know is |
| true, then you should formulate a proof about why the property is true. |
| Your proof depends on some set of facts about the program and its |
| operation. State them completely; for example, don't write ``the field |
| \<f> cannot be null when execution reaches line 22'', but justify |
| \emph{why} the field cannot be null. |
| |
| Once you have written down your proof, translate each fact into a Java |
| annotation. |
| |
| If you are unable to express some aspect of your proof as an annotation, |
| then the type system is not capable of reproducing your proof. You might |
| need to find a different proof, or extend the type system to be more |
| expressive, or suppress the warning. |
| |
| If you are able to express your entire proof as annotations, then look at |
| the Checker Framework error messages. |
| \begin{itemize} |
| \item |
| Perhaps your proof was incomplete or incorrect. Your proof might |
| depend on some fact you didn't write down, such as ``method |
| \<m> has no side effects.'' In this case, you should revise your proof |
| and add more annotations to your Java code. |
| \item |
| Perhaps your proof is incorrect, and the errors indicate where. |
| \item |
| Perhaps there is a bug in the type-checker. In this case, |
| you should report it to the maintainers, giving your proof and explaining |
| why the type-checker should be able to make the same inferences that you did. |
| \end{itemize} |
| |
| Recall that the Checker Framework does modular verification, |
| one procedure at a time; it observes the specifications, but not the |
| implementations, of other methods. |
| |
| Also see Section~\ref{handling-warnings}, which explains this same |
| methodology in different words. |
| |
| \item |
| If a checker seems to be ignoring the annotation on a method, then it is |
| possible that the checker is reading the method's signature from its |
| \code{.class} file, but the \code{.class} file was not created by a Java 8 |
| or later compiler. |
| You can check whether the annotations actually appear in the |
| \code{.class} file by using the \code{javap} tool. |
| |
| If the annotations do not appear in the \code{.class} file, here are two |
| ways to solve the problem: |
| \begin{itemize} |
| \item |
| Re-compile the method's class with the Checker Framework compiler. This will |
| ensure that the type annotations are written to the class file, even if |
| no type-checking happens during that execution. |
| \item |
| Pass the method's file explicitly on the command line when type-checking, |
| so that the compiler reads its source code instead of its \code{.class} |
| file. |
| \end{itemize} |
| |
| \item |
| If a checker issues a warning about a property that it accepted (or that |
| was checked) on a previous line, then probably there was a side-effecting |
| method call in between that could invalidate the property. For example, in |
| this code: |
| |
| \begin{Verbatim} |
| if (currentOutgoing != null && !message.isCompleted()) { |
| currentOutgoing.continueBuffering(message); |
| } |
| \end{Verbatim} |
| |
| \noindent |
| the Nullness Checker will issue a warning on the second line: |
| \begin{Verbatim} |
| warning: [dereference.of.nullable] dereference of possibly-null reference currentOutgoing |
| currentOutgoing.continueBuffering(message); |
| ^ |
| \end{Verbatim} |
| |
| If \<currentOutgoing> is a field rather than a local variable, and |
| \<isCompleted()> is not a pure method, then a null pointer |
| dereference can occur at the given location, because \<isCompleted()> might set |
| the field \<currentOutgoing> to \<null>. |
| |
| If you want to communicate that |
| isCompleted() does not set the field \<currentOutgoing> to \<null>, you can use |
| \<\refqualclass{dataflow/qual}{Pure}>, |
| \<\refqualclass{dataflow/qual}{SideEffectFree}>, |
| or \<\refqualclass{checker/nullness/qual}{EnsuresNonNull}> on the |
| declaration of \<isCompleted()>; see Sections~\ref{type-refinement-purity} |
| and~\ref{nullness-method-annotations}. |
| |
| |
| \item |
| If a checker issues a type-checking error for a call that the library's |
| documentation states is correct, then maybe that library method has not yet |
| been annotated, so default annotations are being used. |
| |
| To solve the problem, add the missing annotations to the library (see |
| Chapter~\ref{annotating-libraries}). The |
| annotations might appear in stub files (which appear |
| in an \code{.astub} file together with the checker's source code) |
| or in the form of annotated libraries (which appear |
| in \url{https://github.com/typetools/}). |
| |
| \item |
| If the compiler reports that it cannot find a method from the JDK or |
| another external library, then maybe the stub file for that class |
| is incomplete. |
| |
| To solve the problem, add the missing annotations to the library, as |
| described in the previous item. |
| |
| The error might take one of these forms: |
| |
| \begin{Verbatim} |
| method sleep in class Thread cannot be applied to given types |
| cannot find symbol: constructor StringBuffer(StringBuffer) |
| \end{Verbatim} |
| |
| \item |
| If you get an error related to a bounded type parameter and a literal such |
| as \<null>, the problem may be missing defaulting. Here is an example: |
| |
| \begin{Verbatim} |
| mypackage/MyClass.java:2044: warning: incompatible types in assignment. |
| T retval = null; |
| ^ |
| found : null |
| required: T extends @MyQualifier Object |
| \end{Verbatim} |
| |
| \noindent |
| A value that can be assigned to a variable of type \<T extends @MyQualifier |
| Object> only if that value is of the bottom type, since the bottom type is |
| the only one that is a subtype of every subtype of \<T extends @MyQualifier |
| Object>. The value \<null> satisfies this for the Java type system, and it |
| must be made to satisfy it for the pluggable type system as well. The |
| typical way to address this is to call \<addStandardLiteralQualifiers> on the \<LiteralTreeAnnotator>. |
| |
| \item |
| An error such as |
| |
| \begin{Verbatim} |
| MyFile.java:123: error: incompatible types in argument. |
| myModel.addElement("Scanning directories..."); |
| ^ |
| found : String |
| required: ? extends Object |
| \end{Verbatim} |
| |
| \noindent |
| may stem from use of raw types. (``\<String>'' might be a different type |
| and might have type annotations.) If your declaration was |
| |
| \begin{Verbatim} |
| DefaultListModel myModel; |
| \end{Verbatim} |
| |
| \noindent |
| then it should be |
| \begin{Verbatim} |
| DefaultListModel<String> myModel; |
| \end{Verbatim} |
| |
| Running the regular Java compiler with the \<-Xlint:unchecked> command-line |
| option will help you to find and fix problems such as raw types. |
| |
| |
| \item |
| The error |
| |
| \begin{Verbatim} |
| error: annotation type not applicable to this kind of declaration |
| ... List<@NonNull String> ... |
| \end{Verbatim} |
| |
| \noindent |
| indicates that you are using a definition of \<@NonNull> that is a |
| declaration annotation, which cannot be used in that syntactic location. |
| For example, many legacy annotations such as those listed in |
| Figure~\ref{fig-nullness-refactoring} are declaration annotations. You can |
| fix the problem by instead using a definition of \<@NonNull> that is a type |
| annotation, such as the Checker Framework's annotations; often this only |
| requires changing an \<import> statement. |
| |
| |
| \item |
| If Eclipse gives the warning |
| |
| \begin{Verbatim} |
| The annotation @NonNull is disallowed for this location |
| \end{Verbatim} |
| |
| \noindent |
| then you have the wrong version of the \<org.eclipse.jdt.annotation> |
| classes. Eclipse includes two incompatible versions of these annotations. |
| You want the one with a name like |
| \<org.eclipse.jdt.annotation\_2.0.0.....jar>, which you can find in the |
| \<plugins> subdirectory under the Eclipse installation directory. |
| Add this .jar file to your build path. |
| |
| |
| \item |
| When one formal parameter's annotation references another formal |
| parameter's name, as in this constructor: |
| |
| \begin{smaller} |
| \begin{Verbatim} |
| public String(char value[], @IndexFor("value") int offset, @IndexOrHigh("value") int count) { ... } |
| \end{Verbatim} |
| \end{smaller} |
| |
| \noindent |
| you will get an error such as |
| |
| \begin{smaller} |
| \begin{Verbatim}[] |
| [expression.unparsable] Expression in dependent type annotation invalid: |
| Use "#1" rather than "value" |
| \end{Verbatim} |
| \end{smaller} |
| |
| Section~\ref{java-expressions-as-arguments} explains that you need to use |
| a different syntax to refer to a formal parameter: |
| |
| \begin{smaller} |
| \begin{Verbatim} |
| public String(char value[], @IndexFor("#1") int offset, @IndexOrHigh("#1") int count) { ... } |
| \end{Verbatim} |
| \end{smaller} |
| |
| |
| \item |
| \label{false-positive-in-dead-code} |
| The Checker Framework can issue false positive warnings in dead code. An |
| example is |
| |
| \begin{smaller} |
| \begin{Verbatim} |
| void m() { |
| String t = ""; |
| t.toString(); |
| try { |
| } catch (Throwable e) { |
| t.toString(); // Nullness Checker issues spurious (dereference.of.nullable) |
| } |
| \end{Verbatim} |
| \end{smaller} |
| |
| \item |
| If the Checker Framework issues an error or warning that you cannot |
| reproduce using a smaller test case, then try running the Checker |
| Framework with the \<-AatfDoNotCache> command-line argument. If the |
| Checker Framework behaves differently with and without that command-line |
| argument, then there is a bug related to its internal caches. Please |
| report that bug at |
| \url{https://github.com/typetools/checker-framework/issues}. |
| |
| \end{itemize} |
| |
| |
| \subsectionAndLabel{Unexpected compilation output when running javac without a pluggable type-checker}{common-problems-running-javac} |
| |
| A message of the form |
| |
| \begin{Verbatim} |
| error: annotation values must be of the form 'name=value' |
| @LTLengthOf("firstName", "lastName") int index; |
| ^ |
| \end{Verbatim} |
| |
| \noindent |
| is caused by incorrect Java syntax. When you supply a set of multiple |
| values as an annotation argument, you need to put curly braces around them: |
| |
| \begin{Verbatim} |
| @LTLengthOf({"firstName", "lastName"}) int index; |
| \end{Verbatim} |
| |
| |
| \sectionAndLabel{How to report problems (bug reporting)}{reporting-bugs} |
| |
| If you have a problem with any checker, or with the Checker Framework, |
| please file a bug at |
| \url{https://github.com/typetools/checker-framework/issues}. |
| (First, check whether there is an existing bug report for that issue.) |
| If the problem is with an incorrect or missing annotation on a library, |
| including the JDK, see Section~\ref{reporting-bugs-annotated-libraries}. |
| You can also use the issue tracker to make suggestions and feature |
| requests. We also welcome pull requests with annotated libraries, bug |
| fixes, new features, new checkers, and other improvements. |
| |
| Please ensure that your bug report is clear and that it is complete. |
| Otherwise, we may be unable to understand it or to reproduce it, either of |
| which would prevent us from helping you. Your bug report should include at |
| least the following 4 parts: commands, inputs, outputs, and expectation. |
| |
| % If you update this, also update ../../.github/ISSUE_TEMPLATE |
| \begin{description} |
| \item[Commands] |
| Provide one or more commands that can be pasted into a command shell to |
| reproduce the problem. |
| |
| In the simplest case, you will provide one command of |
| the form \<javac -processor ... MyFile.java>. In more complex cases, it |
| might be a set of commands clone a repository, check out a branch, and |
| run a build command. Include commands to install software and set |
| environment variables if necessary. |
| |
| If you encountered the problem in an IDE, reproduce it from the command |
| line; if you cannot, report the bug to the IDE integration. |
| |
| It can be helpful to add \\ |
| \code{-version -Aversion -AprintGitProperties -verbose -AprintVerboseGenerics} \\ |
| to the javac options. This causes the |
| compiler to output debugging information, including its version number. |
| |
| \item[Inputs] |
| Include all files that are necessary to reproduce the problem. This |
| includes every file that is used by any of the commands you reported, and |
| possibly other files as well. This is not necessary if the commands you |
| provided obtain the code that is type-checked. |
| |
| If you cannot share your code, create a new, small test case. (A small |
| test case is helpful even if your code is not secret!) If the Checker |
| Framework crashed, the progress tracing options |
| (Section~\ref{creating-debugging-options-progress}) can be helpful in |
| determining which file the Checker Framework was processing when it |
| crashed. |
| |
| \emph{Minimization:} |
| If your command invokes a build system such as Gradle or Maven, it can be |
| helpful to the maintainers if you are able to reduce it to a single |
| \<javac> invocation on a single file. |
| This also rules out the possibility that the problem is with the build system |
| integration rather than the checker itself. |
| If you use an invasive |
| annotation processor such as Lombok, then try to reproduce the problem |
| without it --- this will indicate whether the problem is in the Checker |
| Framework proper or in its interaction with Lombok. |
| |
| \item[Output] |
| Indicate exactly what the result was by attaching a file or using |
| cut-and-paste from your command shell. Don't merely describe it in |
| words, don't use a screenshot, and don't provide just part of the output. |
| |
| \item[Expectation] |
| If the problem is not a crash, then |
| indicate what you expected the result to be, since a bug is a difference |
| between desired and actual outcomes. Also, please indicate \textbf{why} |
| you expected that result --- explaining your reasoning can reveal |
| how your reasoning is different than the checker's and which |
| one is wrong. Remember that the checker reasons modularly and |
| intraprocedurally: it examines one method at a time, using only the |
| method signatures of other methods. |
| |
| It can also be helpful to indicate what you have already done to try to |
| understand the problem. Did you do any additional experiments? What |
| parts of the manual did you read, and what else did you search for in the |
| manual? Without this information, the maintainers may give you redundant |
| suggestions or may waste time re-doing work you have already done. |
| \end{description} |
| |
| % A particularly useful format for a test case is as a new file, or a diff to |
| % an existing file, for the existing Checker Framework test suite. For |
| % instance, for the Nullness |
| % Checker, see directory \<checker-framework/checker/tests/nullness/>. |
| % But, please report your bug even if you do not report it in this format. |
| |
| When reporting bugs, please focus on realistic scenarios and well-written |
| code. We are sure that you can make up artificial code that stymies the |
| type-checker! Those aren't a good use of your time to report nor the |
| maintainers' time to evaluate and fix. |
| |
| |
| \subsectionAndLabel{Problems with annotated libraries}{reporting-bugs-annotated-libraries} |
| |
| If a checker reports a warning because a library contains \emph{incorrect} annotations, |
| then please open a pull request that adds the annotations. If the |
| library's maintainers have added annotations, make a pull request to them. |
| If the Checker Framework maintainers have added annotations, |
| you can find the annotated source in \url{https://github.com/typetools/}. |
| |
| If a checker reports a warning because a library is \emph{not |
| annotated}, please do not open a GitHub issue. |
| Instead, we appreciate pull requests to help us improve the annotations. |
| Alternatively or in the interim, you can use stub files as described in |
| Section~\ref{stub}. |
| |
| For either approach, please see \chapterpageref{annotating-libraries} for |
| tips about writing library annotations. |
| |
| Thanks for your contribution to the annotated libraries! |
| |
| |
| \sectionAndLabel{Building from source}{build-source} |
| |
| The Checker Framework release (Section~\ref{installation}) contains |
| everything that most users need, both to use the distributed checkers and |
| to write your own checkers. This section describes how to compile its |
| binaries from source. You will be using the latest development version of |
| the Checker Framework, rather than an official release. |
| |
| % Doing |
| % so permits you to examine and modify the implementation of the distributed |
| % checkers and of the checker framework. It may also help you to debug |
| % problems more effectively. |
| |
| Note the JDK requirements (Section~\ref{installation}). |
| |
| |
| \subsectionAndLabel{Install prerequisites}{building-prerequisites} |
| |
| You need to install several packages in order to build the Checker |
| Framework. |
| Follow the instructions for your operating system. |
| If your OS is not listed, adapt the instructions for an existing OS; |
| for example, other Linux distributions will be similar to Ubuntu. |
| |
| % Why is this necessary? What goes wrong if it is not set? Can I avoid |
| % the need to set it? It's used for: |
| % * the location of tools.jar, below. |
| % * the default location of CTSYM, in checker/jdk/Makefile. |
| Put the setting of the \<JAVA\_HOME> environment variable in a startup file |
| such as \<.bash\_profile> or \<.bashrc>, if \<JAVA\_HOME> is not already |
| set appropriately. It must be the location of your JDK 8 or JDK 11 |
| installation (not the JRE installation, and not JDK 7 or earlier). |
| You may need to log out and log back in for the setting to take effect. |
| |
| \begin{description} |
| \item[Ubuntu] |
| Run the following commands: |
| |
| % Keep this up to date with ../../checker/bin-devel/Dockerfile-ubuntu-jdk11-plus |
| \begin{Verbatim} |
| sudo apt-get -qqy update |
| sudo apt-get -qqy install \ |
| openjdk-11-jdk \ |
| ant cpp git gradle jq libcurl3-gnutls \ |
| make maven mercurial python3-pip python3-requests unzip wget \ |
| dia hevea imagemagick latexmk librsvg2-bin maven rsync \ |
| texlive-font-utils texlive-fonts-recommended \ |
| texlive-latex-base texlive-latex-extra texlive-latex-recommended |
| pip3 install html5validator |
| \end{Verbatim} |
| |
| You may have to answer questions about which time zone your computer is in. |
| |
| In a startup file, write: |
| % Can someone give a simpler command? |
| % Command taken from: |
| % https://github.com/typetools/checker-framework/blob/master/checker/bin-devel/build.sh#L19 |
| %BEGIN LATEX |
| \begin{smaller} |
| %END LATEX |
| \begin{Verbatim} |
| export JAVA_HOME=${JAVA_HOME:-$(dirname "$(dirname "$(readlink -f "$(which javac)")")")} |
| \end{Verbatim} |
| %BEGIN LATEX |
| \end{smaller} |
| %END LATEX |
| |
| \item[Mac OS] |
| If you employ \ahref{https://brew.sh}{homebrew} to install packages, run |
| the following commands: |
| |
| \begin{Verbatim} |
| brew update |
| brew install git ant hevea maven mercurial librsvg unzip make |
| brew tap AdoptOpenJDK/openjdk |
| brew install --cask adoptopenjdk11 |
| brew install --cask mactex |
| \end{Verbatim} |
| |
| Make a \<latex> directory and copy \<hevea.sty> file into it (you may need to update the version number \<2.31>): |
| |
| \begin{Verbatim} |
| mkdir -p $HOME/Library/texmf/tex/latex |
| cp -p /usr/local/Cellar/hevea/2.31/lib/hevea/hevea.sty $HOME/Library/texmf/tex/latex/ |
| \end{Verbatim} |
| |
| Note: If copy permission is denied, try \<sudo>. |
| |
| In a startup file, write: |
| |
| \begin{Verbatim} |
| export JAVA_HOME=$(/usr/libexec/java_home -v 1.11) |
| \end{Verbatim} |
| or |
| \begin{Verbatim} |
| export JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/ |
| \end{Verbatim} |
| |
| |
| \item[Windows] |
| To build on Windows 10, |
| run \<bash> to obtain a version of |
| Ubuntu (provided by the Windows Subsystem for Linux) and follow the Ubuntu |
| instructions. |
| |
| % To build on other versions of Windows, |
| % here is an \emph{incomplete} list of needed prerequisites: |
| % \begin{itemize} |
| % \item |
| % Install MSYS to obtain the \<cp> and \<make> commands. |
| % \end{itemize} |
| |
| \end{description} |
| |
| |
| \subsectionAndLabel{Obtain the source}{building-obtain-source} |
| |
| Obtain the latest source code from the version control repository: |
| |
| \begin{Verbatim} |
| git clone https://github.com/typetools/checker-framework.git checker-framework |
| export CHECKERFRAMEWORK=`pwd`/checker-framework |
| \end{Verbatim} |
| % $ to unconfuse Emacs LaTeX mode |
| |
| You might want to add an \<export CHECKERFRAMEWORK=...> line to your |
| \<.bashrc> file. |
| |
| |
| \subsectionAndLabel{Build the Checker Framework}{building} |
| |
| % Building (compiling) the checkers and framework from source creates the |
| % \code{checker.jar} file. A pre-compiled \code{checker.jar} is included |
| % in the distribution, so building it is optional. It is mostly useful for |
| % people who are developing compiler plug-ins (type-checkers). If you only |
| % want to \emph{use} the compiler and existing plug-ins, it is sufficient to |
| % use the pre-compiled version. |
| |
| \begin{enumerate} |
| |
| \item |
| Run \code{./gradlew assemble} to build the Checker Framework: |
| |
| \begin{Verbatim} |
| cd $CHECKERFRAMEWORK |
| ./gradlew assemble |
| \end{Verbatim} |
| % $ to unconfuse Emacs LaTeX mode |
| |
| \noindent |
| Your antivirus program (e.g., Windows Security Virus \& threat protection) |
| might make the build run very slowly, or might make it seem to stall. Just |
| give it time. |
| |
| \item |
| Once it is built, you may wish to put the Checker Framework's \<javac> |
| even earlier in your \<PATH>: |
| |
| \begin{Verbatim} |
| export PATH=$CHECKERFRAMEWORK/checker/bin:${PATH} |
| \end{Verbatim} |
| |
| The Checker Framework's \code{javac} ensures that all required |
| libraries are on your classpath and boot classpath, but is otherwise |
| identical to the javac Java compiler. |
| |
| Putting the Checker Framework's \<javac> earlier in your \<PATH> will |
| ensure that the Checker Framework's version is used. |
| |
| \item Test that everything works: |
| |
| \begin{itemize} |
| |
| \item Run \code{./gradlew allTests}: |
| \begin{Verbatim} |
| cd $CHECKERFRAMEWORK |
| ./gradlew allTests |
| \end{Verbatim} |
| % $ to unconfuse Emacs LaTeX mode |
| |
| \item Run the Nullness Checker examples (see |
| Section~\refwithpage{nullness-example}). |
| |
| \end{itemize} |
| |
| \end{enumerate} |
| |
| |
| \subsectionAndLabel{Build the Checker Framework Manual (this document)}{building-manual} |
| |
| \begin{enumerate} |
| \item |
| Install needed packages; see Section~\ref{building-prerequisites} for |
| instructions. |
| |
| \item |
| Run \code{make} in the \code{docs/manual} directory to build both the PDF and HTML versions of the manual. |
| \end{enumerate} |
| |
| |
| \subsectionAndLabel{Code style, IDE configuration, pull requests, etc.}{building-developer-manual} |
| |
| Please see the |
| \href{https://rawgit.com/typetools/checker-framework/master/docs/developer/developer-manual.html}{Checker Framework Developer Manual}. |
| |
| |
| \subsectionAndLabel{Enable continuous integration builds}{building-ci} |
| |
| We strongly recommend that you enable continuous integration (CI) builds on |
| your fork of the projects, so that you learn quickly about errors. See the |
| \ahref{https://rawgit.com/typetools/checker-framework/master/docs/developer/developer-manual.html\#ci}{CI |
| instructions} in the Checker Framework Developer Manual. |
| |
| |
| \subsubsectionAndLabel{Debugging continuous integration builds}{building-ci-debug} |
| |
| If a continuous integration job is failing, you can reproduce the problem locally. |
| The CI jobs all run within Docker containers. |
| Install Docker on your local computer, then perform commands like the |
| following to get a shell within Docker: |
| |
| \begin{Verbatim} |
| docker pull mdernst/cf-ubuntu-jdk8 |
| docker run -it mdernst/cf-ubuntu-jdk8 /bin/bash |
| \end{Verbatim} |
| |
| Then, you can run arbitrary commands, including those that appear in the |
| CI configuration files. |
| |
| |
| \sectionAndLabel{Contributing}{contributing} |
| |
| We welcome contributions and pull requests. Section~\ref{build-source} |
| tells you how to set up your development environment to compile the Checker |
| Framework, and the |
| \href{https://rawgit.com/typetools/checker-framework/master/docs/developer/developer-manual.html}{Checker |
| Framework Developer Manual} gives more information. |
| |
| One good way to contribute is to give feedback about your use of the tool. |
| There is a list |
| of potential projects for new contributors at \url{https://rawgit.com/typetools/checker-framework/master/docs/developer/gsoc-ideas.html}. |
| Or, you can fix a bug that |
| you have encountered during your use of the Checker Framework. |
| |
| |
| \subsectionAndLabel{Contributing fixes (creating a pull request)}{pull-request} |
| |
| Please see the |
| \ahref{https://rawgit.com/typetools/checker-framework/master/docs/developer/developer-manual.html#pull-requests}{pull |
| requests} section of the Checker Framework Developer Manual. |
| Thanks in advance for your contributions! |
| |
| The easiest bugs to fix for a newcomer are |
| \ahref{https://github.com/typetools/checker-framework/issues?q=is\%3Aopen+is\%3Aissue+label\%3A\%22help+wanted\%22}{labeled |
| as ``help wanted''}. |
| |
| Please do not spam the issue tracker with requests to assign an issue to |
| you. If you want to contribute by fixing an issue, just open a pull |
| request that fixes it. You can do that even if the issue is already |
| assigned to someone. |
| |
| Please do not spam the issue tracker asking how to get started fixing a |
| bug. If you have concrete questions, please ask them and we will be happy |
| to assist you. If you don't know how to get started fixing a particular |
| bug, then you should contribute to the project in other ways. Thanks! |
| |
| |
| \sectionAndLabel{Publications}{publications} |
| |
| Here are two technical papers about the Checker Framework itself: |
| |
| \begin{itemize} |
| \item |
| ``Practical pluggable types for Java''~\cite{PapiACPE2008} |
| (ISSTA 2008, \myurl{https://homes.cs.washington.edu/~mernst/pubs/pluggable-checkers-issta2008.pdf}) |
| describes the design and implementation of the Checker Framework. |
| The paper also describes case |
| studies in which the Nullness, Interning, Javari, and IGJ Checkers found |
| previously-unknown errors in real software. |
| The case studies also yielded new insights about type systems. |
| |
| \item |
| ``Building and using pluggable |
| type-checkers''~\cite{DietlDEMS2011} |
| (ICSE 2011, \myurl{https://homes.cs.washington.edu/~mernst/pubs/pluggable-checkers-icse2011.pdf}) |
| discusses further experience with the Checker Framework, increasing the |
| number of lines of verified code to 3 million. The case studies are of the |
| Fake Enum, Signature String, Interning, and Nullness Checkers. |
| The paper also evaluates the ease |
| of pluggable type-checking with the Checker Framework: type-checkers |
| were easy to write, easy for novices to use, and effective in finding |
| errors. |
| \end{itemize} |
| |
| Here are some papers about type systems that were implemented and evaluated |
| using the Checker Framework: |
| |
| \begin{description} |
| \item[Nullness (Chapter~\ref{nullness-checker})] |
| See the two papers about the Checker Framework, described above. |
| |
| \item[Rawness initialization (Section~\ref{initialization-rawness-checker})] |
| ``Inference of field initialization'' (ICSE 2011, \myurl{https://homes.cs.washington.edu/~mernst/pubs/initialization-icse2011-abstract.html}) |
| describes inference for the Rawness Initialization Checker. |
| |
| \item[Interning (Chapter~\ref{interning-checker})] |
| See the two papers about the Checker Framework, described above. |
| |
| \item[Locking (Chapter~\ref{lock-checker})] |
| ``Locking discipline inference and checking'' (ICSE 2016, |
| \myurl{https://homes.cs.washington.edu/~mernst/pubs/locking-inference-checking-icse2016-abstract.html}) |
| describes the Lock Checker. |
| |
| \item[Fake enumerations, type aliases, and typedefs (Chapter~\ref{fenum-checker})] |
| See the ICSE 2011 paper about the Checker Framework, described above. |
| |
| \item[Regular expressions (Chapter~\ref{regex-checker})] |
| ``A type system for regular expressions''~\cite{SpishakDE2012} (FTfJP 2012, \myurl{https://homes.cs.washington.edu/~mernst/pubs/regex-types-ftfjp2012-abstract.html}) |
| describes the Regex Checker. |
| |
| \item[Format Strings (Chapter~\ref{formatter-checker})] |
| ``A type system for format strings''~\cite{WeitzKSE2014} (ISSTA 2014, \myurl{https://homes.cs.washington.edu/~mernst/pubs/format-string-issta2014-abstract.html}) |
| describes the Format String Checker. |
| |
| \item[Signature strings (Chapter~\ref{signature-checker})] |
| See the ICSE 2011 paper about the Checker Framework, described above. |
| |
| \item[GUI Effects (Chapter~\ref{guieffect-checker})] |
| ``JavaUI: Effects for controlling UI object access''~\cite{GordonDEG2013} (ECOOP 2013, \myurl{https://homes.cs.washington.edu/~mernst/pubs/gui-thread-ecoop2013-abstract.html}) |
| describes the GUI Effect Checker. |
| |
| \item |
| ``Verification games: Making verification fun'' (FTfJP 2012, \myurl{https://homes.cs.washington.edu/~mernst/pubs/verigames-ftfjp2012-abstract.html}) |
| describes a general inference approach that, at the time, had only been implemented for the Nullness Checker (Section~\ref{nullness-checker}). |
| |
| \item[Thread locality (Section~\ref{loci-thread-locality-checker})] |
| ``Loci: Simple thread-locality for Java''~\cite{WrigstadPMZV2009} (ECOOP 2009, |
| \myurl{http://janvitek.org/pubs/ecoop09.pdf}) |
| |
| \item[Security (Section~\ref{sparta-checker})] |
| ``Static analysis of implicit control flow: Resolving Java reflection and |
| Android intents''~\cite{BarrosJMVDdAE2015} (ASE 2015, |
| \myurl{https://homes.cs.washington.edu/~mernst/pubs/implicit-control-flow-ase2015-abstract.html}) |
| describes the SPARTA toolset and information flow type-checker. |
| |
| ``Boolean formulas for the static identification of injection attacks in |
| Java''~\cite{ErnstLMSS2015} (LPAR 2015, \myurl{https://homes.cs.washington.edu/~mernst/pubs/detect-injections-lpar2015-abstract.html}) |
| |
| \item[\href{https://ece.uwaterloo.ca/~wdietl/ownership/}{Generic Universe |
| Types} (Section~\ref{gut-checker})] |
| ``Tunable static inference for Generic Universe Types'' (ECOOP 2011, \myurl{https://homes.cs.washington.edu/~mernst/pubs/tunable-typeinf-ecoop2011-abstract.html}) |
| describes inference for the Generic Universe Types type system. |
| |
| Another implementation of Universe Types and \href{http://www.cs.rpi.edu/~huangw5/cf-inference/}{ownership types} is described in |
| ``Inference and checking of object ownership''~\cite{HuangDME2012} (ECOOP 2012, \myurl{https://homes.cs.washington.edu/~mernst/pubs/infer-ownership-ecoop2012-abstract.html}). |
| |
| \item[Approximate data (Section~\ref{enerj-checker})] |
| ``EnerJ: Approximate Data Types for Safe and General Low-Power Computation''~\cite{SampsonDFGCG2011} (PLDI 2011, \myurl{https://homes.cs.washington.edu/~luisceze/publications/Enerj-pldi2011.pdf}) |
| |
| \item[Information flow and tainting (Section~\ref{sparta-checker})] |
| ``Collaborative Verification of Information Flow |
| for a High-Assurance App Store''~\cite{ErnstJMDPRKBBHVW2014} (CCS 2014, \myurl{https://homes.cs.washington.edu/~mernst/pubs/infoflow-ccs2014.pdf}) describes the SPARTA information flow type system. |
| |
| \item[IGJ and OIGJ immutability (Section~\ref{igj-checker})] |
| ``Object and reference immutability using Java generics''~\cite{ZibinPAAKE2007} (ESEC/FSE 2007, \myurl{https://homes.cs.washington.edu/~mernst/pubs/immutability-generics-fse2007-abstract.html}) |
| and |
| ``Ownership and immutability in generic Java''~\cite{ZibinPLAE2010} (OOPSLA 2010, \myurl{https://homes.cs.washington.edu/~mernst/pubs/ownership-immutability-oopsla2010-abstract.html}) |
| describe the IGJ and OIGJ immutability type systems. |
| For further case studies, also see the ISSTA 2008 paper about the Checker |
| Framework, described above. |
| |
| \item[Javari immutability (Section~\ref{javari-checker})] |
| ``Javari: Adding reference immutability to Java''~\cite{TschantzE2005} (OOPSLA 2005, \myurl{https://homes.cs.washington.edu/~mernst/pubs/ref-immutability-oopsla2005-abstract.html}) |
| describes the Javari type system. |
| For inference, see |
| ``Inference of reference immutability''~\cite{QuinonezTE2008} (ECOOP 2008, \myurl{https://homes.cs.washington.edu/~mernst/pubs/infer-refimmutability-ecoop2008-abstract.html}) |
| and |
| ``Parameter reference immutability: Formal definition, inference tool, and comparison''~\cite{ArtziQKE2009} (J.ASE 2009, \myurl{https://homes.cs.washington.edu/~mernst/pubs/mutability-jase2009-abstract.html}). |
| For further case studies, also see the ISSTA 2008 paper about the Checker |
| Framework, described above. |
| |
| \item[ReIm immutability] |
| % TODO: (Section~\ref{reim-checker}) |
| ``ReIm \& ReImInfer: Checking and inference of reference immutability and method purity''~\cite{HuangMDE2012} (OOPSLA 2012, \myurl{https://homes.cs.washington.edu/~mernst/pubs/infer-refimmutability-oopsla2012-abstract.html}) |
| describes the ReIm immutability type system. |
| |
| \end{description} |
| |
| In addition to these papers that discuss use the Checker Framework |
| directly, other academic papers use the Checker Framework in their |
| implementation or evaluation. |
| Most educational use of the Checker |
| Framework is never published, and most commercial use of the Checker |
| Framework is never discussed publicly. |
| |
| (If you know of a paper or other use that is not listed here, please inform |
| the Checker Framework developers so we can add it.) |
| |
| |
| \sectionAndLabel{Credits and changelog}{credits} |
| |
| Differences from previous versions of the checkers and framework can be found |
| in the \code{docs/CHANGELOG.md} file. This file is included in the |
| Checker Framework distribution and is also available on the web at |
| \myurl{https://checkerframework.org/CHANGELOG.md}. |
| |
| Developers who have contributed code to the Checker Framework include |
| \input{contributors.tex} |
| In addition, too many users to list have provided valuable feedback, which |
| has improved the toolset's design and implementation. |
| Thanks for your help! |
| |
| |
| \sectionAndLabel{License}{license} |
| |
| Two different licenses apply to different parts of the Checker Framework. |
| \begin{itemize} |
| \item |
| The Checker Framework itself is licensed under the GNU General Public License |
| (GPL), version 2, with the classpath exception. |
| The GPL is the same license that OpenJDK is licensed |
| under. Just as compiling your code with javac does not infect your code |
| with the GPL, type-checking your code with the Checker Framework does not |
| infect your code with the GPL\@. Running the Checker Framework during |
| development has no effect on your intellectual property or licensing. If |
| you want to ship the Checker Framework as part of your product, then your |
| product must be licensed under the GPL\@. |
| \item |
| The more permissive MIT License applies |
| to code that you might want to include in your own |
| program, such as the annotations and run-time utility classes. |
| \end{itemize} |
| \noindent |
| For details, see file |
| \ahref{https://raw.githubusercontent.com/typetools/checker-framework/master/LICENSE.txt}{\<LICENSE.txt>}. |
| |
| |
| |
| % LocalWords: jsr unsetting plugins langtools zipfile cp plugin Nullness txt |
| % LocalWords: nullness classpath NonNull MyObject javac uref changelog MyEnum |
| % LocalWords: subtyping containsKey proc classfiles SourceChecker javap jdk |
| % LocalWords: MyFile buildfiles ClassName JRE java bootclasspath |
| % LocalWords: extJavac ZipFile AnoPrintErrorStack AprintAllQualifiers Jlint |
| % LocalWords: Telmo Correa Papi NoSuchFieldError ZipException Xlint A1 |
| % LocalWords: FileNotFoundException MyQualifier ImplicitFor A2 A3 JDKs |
| % LocalWords: StaticNestedClass StaticNested ConfusingAnnotation pre yml |
| %% LocalWords: CHECKERFRAMEWORK currentOutgoing isCompleted ElementType |
| %% LocalWords: EnsuresNonNull devel javacutil stubparser rsvg Regex IGJ |
| %% LocalWords: JavaUI EnerJ App CCS ReIm ReImInfer Anatoly Kupriyanov ci |
| %% LocalWords: Asumu Takikawa Brotherston McArthur Luo Bayne Coblenz Lai |
| %% LocalWords: Barros Athaydes Ren Oblak Heule Steph Trask Stalnaker |
| %% LocalWords: toolset's typechecking LiteralKind reifiable plaintext |
| %% LocalWords: astub homebrew hevea allTests AatfDoNotCache Java'' |
| %% LocalWords: compileJava typedefs LPAR Tunable OIGJ sudo wanted'' |
| % LocalWords: addStandardLiteralQualifiers AprintGitProperties checkers'' |
| % LocalWords: expressions'' strings'' access'' intents'' ownership'' |
| % LocalWords: Computation'' Store'' generics'' immutability'' purity'' |
| % LocalWords: comparison'' |