Checker Framework logo

New contributor ideas

Contents:

Introduction

The Checker Framework is an innovative programming tool that prevents bugs at development time, before they escape to production.

Java's type system prevents some bugs, such as int count = "hello";. However, it does not prevent other bugs, such as null pointer dereferences, concurrency errors, disclosure of private information, incorrect internationalization, out-of-bounds indices, etc. Pluggable type-checking replaces a programming language's built-in type system with a more powerful, expressive one.

We have created around 20 new type systems, and other people have created many more. The more powerful type system is not just a bug-finding tool: it is a verification tool that gives a guarantee that no errors (of certain types) exist in your program. Even though it is powerful, it is easy to use. It follows the standard typing rules that programmers already know, and it fits into their workflow.

The Checker Framework is popular: it is used daily at Google, Amazon, Uber, on Wall Street, and in other companies from big to small. It is attractive to programmers who care about their craft and the quality of their code. The Checker Framework is the motivation for Java's type annotations feature. It has received multiple awards. With this widespread use, there is a need for people to help with the project: everything from bug fixes, to new features, to case studies, to integration with other tools. We welcome your contribution!

Why should you join this project? It's popular, so you will have an impact. It makes code more robust and secure, which is a socially important purpose. Past GSOC students have had great success. (David Lazar became a graduate student at MIT; multiple students have published papers in scientific conferences, such as Vlastimil Dort at ISSTA 2018.) You will get to scratch your own itch by creating tools that solve problems that frustrate you. And, we have a lot of fun on this project!

Prerequisites: You should be very comfortable with the Java programming language and its type system. You should know how a type system helps you and where it can hinder you. You should be willing to dive into a moderately-sized codebase. You should understand fundamental object-oriented programming concepts, such as behavioral subtyping: subtyping theory permits argument types to change contravariantly (even though Java forbids it for reasons related to overloading), whereas return types may change covariantly both in theory and in Java.

Potential projects: Most of this document lists potential summer projects. The projects are grouped roughly from easiest to most challenging. Many of the projects are applicable beyond Google Summer of Code.

How to get started: do a case study

To get started, first do a case study of using the Checker Framework: that is, run the Checker Framework on some program. A case study gives you experience in using the Checker Framework, and it may reveal bugs in either the Checker Framework or in the program it is analyzing.

Do the case study before submitting your proposal. You might want to start with a small program such as from your coursework, then repeat the process with an open-source program or library.

  1. Install the Checker Framework.
  2. Review the Checker Framework documentation.
  3. Choose an existing library or program to type-check. Choose a program that is at least 1000 lines long. The library or program should be under active maintenance; don't choose one that has not had a commit in several years. You will find the case study easier if you are already familiar with the program, or if it is written in good style.
  4. Choose one type system, from among those distributed with the Checker Framework, that is appropriate for the program.
  5. If the program is hosted on GitHub, fork it and create a branch for your work. (Leave the master branch unchanged from upstream.)
  6. Annotate the program, based on its documentation.
    Please do not make changes unrelated to annotating the program, such as inserting/removing whitespace or sorting the import statements. Doing so bloats the size of the diffs and makes it hard to understand the essential changes.
  7. Change the build system so that building the annotated branch runs the type-checker.
  8. Run the type-checker. If it issues warnings, correct them. This might require adding more annotations, fixing bugs in the program, or suppressing warnings. Be sure that the program's test suite continues to pass. Repeat until the type-checker passes on the program.
  9. Share it with us so that we can evaluate it and give you feedback.

    Share the case study as soon as you finish it or as soon as you have a question that is not answered in the manual; don't wait until you submit your proposal. The subject line should be descriptive (not just "Case study", but "Nullness case study of Apache Commons Exec library"). You should give us access to

    The best way to give all this information is a pointer to your GitHub fork of the library.

The primary result of your case study is that you will discover bugs in the subject program, or you will verify that it has no bugs (of some particular type). If you find bugs in open-source code, report them to the program's maintainer, and let us know when they are resolved.

Another outcome of your case study is that you may discover bugs, limitations, or usability problems in the Checker Framework. Please report them. We'll try to fix them, or they might give you inspiration for improvements you would like to make to the Checker Framework this summer.

You can also try to fix problems yourself and submit a pull request, but that is not a requirement; most successful GSOC applicants had not submitted a successful pull request before being selected. (Some GSOC projects have a requirement to fix an issue in the issue tracker. We do not, because it is unproductive. Don't try to start fixing issues before you understand the Checker Framework from the user point of view, which will not happen until you have completed a case study on an open-source program.) You may discuss your ideas with us by sending mail to checker-framework-gsoc@googlegroups.com.

Why should you start with a case study? Before you can contribute to any project, you must understand the tool from a user point of view, including its strengths, weaknesses, and how to use it. A case study is the best way to learn about the Checker Framework, determine whether you would enjoy joining the project during the summer, and show your aptitude so that you will be chosen for the summer.

How to get help and ask questions

We are very happy to answer your questions, and we are eager to interact with you! It's OK to have questions, and your questions can lead to improvements in the documentation and the tool.

Before you ask a question, read this file and the "Troubleshooting" section of the Checker Framework manual (including "How to report problems"), and also search in the Checker Framework manual for the answer. Don't send us a message that says nothing but “please guide me” or “tell me how to fix this bug”. Such a message disqualifies you from participating in GSOC, because it shows that you do not read instructions, and you haven't thought about the problem nor tried to solve it.

Your questions should show that you will be a productive colleague over the summer: tell us what you have tried, tell us what went wrong or where you got stuck, and ask a concrete technical question that will help you get past your problem. If you can do that, then definitely ask your question, because we don't want you to be stuck or frustrated.

Whenever you send email (related to GSoC or not), please use standard email etiquette, such as: avoid all-caps; use a descriptive subject line; don't put multiple different topics in a single email message; start a new thread with a new subject line when you change the topic; don't clutter discussions with irrelevant remarks; don't use screenshots (unless there is a problem with a GUI), but instead cut-and-paste the output or code into your message; if you are making a guess, clearly indicate that it is a guess and your grounds for it. If you violate these basic rules, you will demonstrate that you don't read instructions and you don't act professionally. Bug reports should be complete and should usually be reported to the issue tracker.

Types of projects

Here are some possible focuses for a project:

This document gives a few suggestions in each category.

How to apply

To apply, you will submit a single PDF through the Google Summer of Code website. This PDF should contain two main parts. We suggest that you number the parts and subparts to ensure that you don't forget anything, and to ensure that we don't overlook anything when reading your application. You might find it easiest to create multiple PDFs for the different parts, then concatenate them before uploading to the website, but how you create your proposal is entirely up to you.

  1. The proposal itself: what project you want to work on during the summer. You might propose to do a project listed on this webpage, or you might propose a different project.

    The proposal should have a descriptive title, both in the PDF and in the GSoC submission system. Don't use a title like "Checker Proposal" or "Proposal for GSoC". Don't distract from content with gratuitous graphics.

    List the tasks or subparts that are required to complete your project. This will help you discover a part that you had forgotten. We do not require a detailed timeline, because you don't yet know enough to create one.

    If you want to do a case study, say what program you will do your case study on.

    If you want to create a new type system (whether one proposed on this webpage or one of your own devising), then your proposal should include the type system's user manual. You don't have to integrate it in the Checker Framework repository (in other words, use any word processor or text editor you want to create a PDF file you will submit), but you should describe your proposed checker's parts in precise English or simple formalisms, and you should follow the suggested structure.

    If you want to do exactly what is already listed on this page, then just say that (but be specific about which one!), and it will not hurt your chances of being selected. However, show us what progress you have made so far. You might also give specific ideas about extensions, about details that are not mentioned on this webpage, about implementation strategies, and so forth.

    Never literally cut-and-paste text that was not written by you, because that would be plagiarism. If you quote from text written by someone else, give proper credit. Don't submit a proposal that is just a rearrangement of text that already appears on this page or in the Checker Framework manual, because it does not help us to assess your likelihood of being successful.

  2. Your qualifications. Please convince us that you are likely to be successful in your proposed summer project.
    1. A URL that points to a code sample. Don't write any new code, but provide code you wrote in the past, such as for a class assignment or a project you have worked on outside class. It does not need to have anything to do with the Checker Framework project. It should be your own personal work. The purpose is to assess your programming skills so we can assign you to an appropriate project. A common problem is to submit undocumented code; we expect every programmer to write documentation when working on the Checker Framework. Don't put a lot of different files in Google Drive and share that URL; it's better to upload a single .zip file or provide a GitHub URL.
    2. What you have done to prepare yourself for working with the Checker Framework during the summer. You may wish to structure this as a list. Examples of items in the list include:
      • A URL for code you have annotated as a case study. Please indicate the original unannotated code, the annotated code, and the exact command to run the type-checker from the command line. Ensure that the GSoC mentors can compile your code. (It is acceptable to use the same code, or different code, for this item and the code sample above.)
      • URLs for bugs or pull requests that you have filed.
      • Information about other projects you have done, or classes you have taken, that prepare you for your proposed summer task. This is optional, because it might already appear in your resume.
    3. A resume. A resume contains a brief description of your skills and your job or project experience. It will often list classes you have taken so far and your GPA. It should not be longer than one page.
    4. An unofficial transcript or grade report (don't spend money for an official one).

The best way to impress us is by doing a thoughtful job in the case study. The case study is even more important than the proposal text, because it shows us your abilities. The case study may result in you submitting issues against the issue tracker of the program you are annotating or of the Checker Framework. Pull requests against our GitHub project are a plus but are not required: good submitted bugs are just as valuable as bug fixes! You can also make a good impression by correctly answering questions from other students on the GSOC mailing list.

Get feedback! Feel free to ask questions to make your application more competitive. We want you to succeed. Historically, students who start early and get feedback are most successful. You can submit a draft proposal via the Google Summer of Code website, and we will review it. We do not receive any notification when you submit a draft proposal, so if you want feedback, please tell us that. Also, we can only see draft proposals; we cannot see final proposals until after the application deadline has passed.

Evaluate a type system or a Checker Framework feature

These projects evaluate a recently-written type system or a feature used by multiple type systems. Using the type systems on real code is our most important source of new ideas and improvements. Many people have started out “just” doing a case study but have ended up making deep, fundamental contributions and even publishing scientific papers about their discoveries.

One possible outcome is to identify weaknesses in the type-checker so that we can improve it. Another possible outcome is to provide evidence that the type-checker is effective and convince more users to adopt it. You will probably also discover defects (bugs) in the codebase being type-checked.

Signature strings

Determine whether the ASM library, or some other library, properly handles signature strings.

Some challenging aspects of this case study are:

Signed and unsigned numbers

The Signedness Checker ensures that you do not misuse unsigned values, such as by mixing signed and unsigned values in a computation or by performing a meaningless operation.

Perform a case study of the Signedness Checker, in order to detect errors or guarantee that code is correct.

A good way to find projects that use unsigned arithmetic is to find a library that supports unsigned arithmetic, then search on GitHub for projects that use that library.

Here are some relevant libraries.

Another possibility is to find Java projects that could use an unsigned arithmetic library but do not. For example, bc-java defines its own unsigned libraries, and some other programs might do direct bit manipulation.

Your case studies will show the need for enhancements to the Signedness Checker. For example, the Signedness Checker does not currently handle boxed integers and BigInteger; these haven't yet come up in case studies but could be worthwhile enhancements. You may also need to write more annotations for libraries such as the JDK.

Java's Optional class

Java 8 introduced the Optional class, a container that is either empty or contains a non-null value. It is intended to solve the problem of null pointer exceptions. However, Optional has its own problems.

Because of Optional's problems, many commentators advise programmers to use Optional only in limited ways.

The goal of this project is to evaluate the Optional Checker, which warns programmers who have misused Optional. Another goal is to extend the Optional Checker to make it more precise or to detect other misuses of Optional.

Whole-program type inference

A type system is useful because it prevents certain errors. The downside of a type system is the effort required to write the types. Type inference is the process of writing the types for a program.

The Checker Framework includes a whole-program inference that inserts type qualifiers in the user's program. It works well on some programs, but needs more enhancements to work well on all programs.

Determinism

Programs are easier to use and debug if their output is deterministic. For example, it is easier to test a deterministic program, because nondeterminism can lead to flaky tests that sometimes succeed and sometimes fail. As another example, it is easier for a user or programmer to compare two deterministic executions than two nondeterministic executions.

We have created a prototype Determinism Checker. It is documented in this draft manual chapter, and its implementation is in t-rasmud/nondet-checker. You will do a case study of this type system.

Sound checking by default

By default, the Checker Framework is unsound in several circumstances. “Unsound” means that the Checker Framework may report no warning even though the program can misbehave at run time.

The reason that the Checker Framework is unsound is that we believe that enabling these checks would cause too many false positive warnings: warnings that the Checker Framework issues because it cannot prove that the code is safe (even though a human can see that the code is safe). Having too many false positive warnings would irritate users and lead them not to use the checker at all, or would force them to simply disable those checks.

We would like to do studies of these command-line options to see whether our concern is justified. Is it prohibitive to enable sound checking? Or can we think of enhancements that would let us turn on those checks that are currently disabled by default?

There is no need to annotate new code for this project. Just use existing annotated codebases, such as those that are type-checked as part of the Checker Framework's Azure Pipeline. In other words, you can start by enabling Azure Pipelines for your fork and then changing the default behavior in a branch. The Azure Pipelines job will show you what new warnings appear.

Comparison to other tools

Many other tools exist for prevention of programming errors, such as Error Prone, NullAway, FindBugs, JLint, PMD, and IDEs such as Eclipse and IntelliJ. These tools are not as powerful as the Checker Framework (some are bug finders rather than verification tools, and some perform a shallower analysis), but they may be easier to use. Programmers who use these tools wonder, "Is it worth my time to switch to using the Checker Framework?"

The goal of this project is to perform a head-to-head comparison of as many different tools as possible. You will quantify:

This project will help programmers to choose among the different tools — it will show when a programmer should or should not use the Checker Framework. This project will also indicate how each tool should be improved.

One place to start would be with an old version of a program that is known to contain bugs. Or, start with the latest version of the program and re-introduce fixed bugs. (Either of these is more realistic than introducing artificial bugs into the program.) A possibility would be to use the Lookup program that has been used in previous case studies.

Android support annotations

Android uses its own annotations that are similar to some in the Checker Framework. Examples include the Android Studio support annotations, including @NonNull, @IntRange, @IntDef, and others.

The goal of this project is to implement support for these annotations. That is probably as simple as creating aliased annotations by calling method addAliasedTypeAnnotation() in AnnotatedTypeFactory.

Then, do a case study to show the utility (or not) of pluggable type-checking, by comparison with how Android Studio currently checks the annotations.

Annotate a library

These projects annotate a library, so that it is easier to type-check clients of the library. Another benefit is that this may find bugs in the library. It can also give evidence for the usefulness of pluggable type-checking, or point out ways to improve the Checker Framework.

When type-checking a method call, the Checker Framework uses the method declaration's annotations. This means that in order to type-check code that uses a library, the Checker Framework needs an annotated version of the library.

The Checker Framework comes with a few annotated libraries. Increasing this number will make the Checker Framework even more useful, and easier to use.

After you have chosen a library, fork the library's source code, adjust its build system to run the Checker Framework, and add annotations to it until the type-checker issues no warnings.

Before you get started, be sure to read How to get started annotating legacy code. More generally, read the relevant sections of the Checker Framework manual.

Choosing a library to annotate

There are several ways to choose a library to annotate:

When annotating a library, it is important to type-check both the library and at least one client that uses it. Type-checking the client will ensure that the library annotations are accurate.

Whatever library you choose, you will need to deeply understand its source code. You will find it easier to work with a library that is well-designed and well-documented.

You should choose a library that is not already annotated. There are two exceptions to this.

Guava library

Guava is already partially annotated with nullness annotations — in part by Guava's developers, and in part by the Checker Framework team. However, Guava does not yet type-check without errors. Doing so could find more errors (the Checker Framework has found nullness and indexing errors in Guava in the past) and would be a good case study to learn the limitations of the Nullness Checker.

Create a new type system

The Checker Framework is shipped with about 20 type-checkers. Users can create a new checker of their own. However, some users don't want to go to that trouble. They would like to have more type-checkers packaged with the Checker Framework for easy use.

Each of these projects requires you to design a new type system, implement it, and perform case studies to demonstrate that it is both usable and effective in finding/preventing bugs.

Non-Empty Checker for precise handling of Queue.peek() and poll()

The Nullness Checker issues a false positive warning for this code:

import java.util.PriorityQueue;
import org.checkerframework.checker.nullness.qual.NonNull;

public class MyClass {
    public static void usePriorityQueue(PriorityQueue<@NonNull Object> active) {
        while (!(active.isEmpty())) {
            @NonNull Object queueMinPathNode = active.peek();
        }
    }
}

The Checker Framework does not determine that active.peek() returns a non-null value in this context.

The contract of peek() is that it returns a non-null value if the queue is not empty and the queue contains no null values.

To handle this code precisely, the Nullness Checker needs to know, for each queue, whether it is empty. This is analogous to how the Nullness Checker tracks whether a particular value is a key in a map.

It should be handled the same way: by adding a new subchecker, called the Nonempty Checker, to the Nullness Checker. Its types are:

There is a start at this type-checker in branch nonempty-checker. It:

However, it is not done. (In fact, it doesn't even compile.) For information about what needs to be done, see issue #399.

When you are done, the Nullness Checker should issue only the // :: diagnostics from checker/tests/nullness/IsEmptyPoll.java — no more and no fewer. You can test that by running the Nullness Checker on the file, and when you are done you should delete the // @skip-test line so that the file is run as part of the Checker Framework test suite.

Custom tainting checking

The Checker Framework comes with a Tainting Checker that is so general that it is not good for much of anything. In order to be useful in a particular domain, a user must customize it:

The first part of this project is to make this customization easier to do — preferably, a user will not have to change any code in the Checker Framework (the Subtyping Checker already works this way). As part of making customization easier, a user should be able to specify multiple levels of taint — many information classification hierarchies have more than two levels (for example, the US government separates classified information into three categories: Confidential, Secret, and Top Secret).

The second part of this project is to provide several examples, and do case studies showing the utility of compile-time taint checking.

Possible examples include:

For some microbenchmarks, see the Juliette test suite for Java from CWE.

Track unsupported operations

Some objects do not fully implement their interface; they throw UnsupportedOperationException for some operations. One example is unmodifiable collections. They throw the exception when a mutating operation is called, such as add, addAll, put, remove, etc.

Design a type system to track which operations might not be supported. The checker would issue a warning whenever an UnsupportedOperationException might occur at run time.

Here is a possible type hierarchy:

  @MightSupportNothing     ← every hierarchy must have a top type
         |
  @MightNotSupport({"add", remove"})
         |
  @MightNotSupport("add")
         |
  @SupportsAllOperations   ← this is the default type qualifier

@SupportsAllOperations indicates that an object that supports all its documented operations: it never throws UnsupportedOperationException. @MightNotSupport(operations) indicates which methods might throw UnsupportedOperationException. Methods such as Arrays.asList and Collections.emptyList must be annotated to return one of these less-capable supertypes.

(An alternative would be to have annotations that are specific to certain types, such as @MutableList for lists.)

If a program uses no objects that throw UnsupportedOperationException, no annotations are required. Experiments must be done to determine how high the annotation burden is, in a program that extensively uses such objects. If the whole program is available, then type inference can infer the needed types.

Overflow checking

Overflow is when 32-bit arithmetic differs from ideal arithmetic. For example, in Java the int computation 2,147,483,647 + 1 yields a negative number, -2,147,483,648. The goal of this project is to detect and prevent problems such as these.

One way to write this is as an extension of the Constant Value Checker, which already keeps track of integer ranges. It even already checks for overflow, but it never issues a warning when it discovers possible overflow. Your variant would do so.

This problem is so challenging that there has been almost no previous research on static approaches to the problem. (Two relevant papers are IntScope: Automatically Detecting Integer Overflow Vulnerability in x86 Binary Using Symbolic Execution and Integer Overflow Vulnerabilities Detection in Software Binary Code.) Researchers are concerned that users will have to write a lot of annotations indicating the possible ranges of variables, and that even so there will be a lot of false positive warnings due to approximations in the conservative analysis. For example, will every loop that contains i++ cause a warning that i might overflow? That would not be acceptable: users would just disable the check.

You can convince yourself of the difficulty by manually analyzing programs to see how clever the analysis has to be, or manually simulating your proposed analysis on a selection of real-world code to learn its weaknesses. You might also try it on good and bad binary search code.

One way to make the problem tractable is to limit its scope: instead of being concerned with all possible arithmetic overflow, focus on a specific use case. As one concrete application, the Index Checker is currently unsound in the presence of integer overflow. If an integer i is known to be @Positive, and 1 is added to it, then the Index Checker believes that its type remains @Positive. If i was already Integer.MAX_VALUE, then the result is negative — that is, the Index Checker's approximation to it is unsound.

This project involves removing this unsoundness by implementing a type system to track when an integer value might overflow — but this only matters for values that are used as an array index. That is, checking can be restricted to computations that involve an operand of type @IntRange). Implementing such an analysis would permit the Index Checker to extend its guarantees even to programs that might overflow.

This analysis is important for some indexing bugs in practice. Using the Index Checker, we found 5 bugs in Google Guava related to overflow. Google marked these as high priority and fixed them immediately. In practice, there would be a run-time exception only for an array of size approximately Integer.MAX_INT.

You could write an extension of the Constant Value Checker, which already keeps track of integer ranges and even determines when overflow is possible. It doesn't issue a warning, but your checker could record whether overflow was possible (this could be a two-element type system) and then issue a warning, if the value is used as an array index. Other implementation strategies may be possible.

Here are some ideas for how to avoid the specific problem of issuing a warning about potential overflow for every i++ in a loop (but maybe other approaches are possible):

Index checking for mutable length data structures

The Index Checker is currently restricted to fixed-size data structures. A fixed-size data structure is one whose length cannot be changed once it is created, such as arrays and Strings. This limitation prevents the Index Checker from verifying indexing operations on mutable-size data structures, like Lists, that have add or remove methods. Since these kind of collections are common in practice, this is a severe limitation for the Index Checker.

The limitation is caused by the Index Checker's use of types that are dependent on the length of data structures, like @LTLengthOf("data_structure"). If data_structure's length could change, then the correctness of this type might change.

A naive solution would be to invalidate these types any time a method is called on data_structure. Unfortunately, aliasing makes this still unsound. Even more, a great solution to this problem would keep the information in the type when a method like add or remove is called on data_structure. A more complete solution might involve some special annotations on List that permit the information to be persisted.

This project would involve designing and implementing a solution to this problem.

Nullness bug detector

Verifying a program to be free of errors can be a daunting task. When starting out, a user may be more interested in bug-finding than verification. The goal of this project is to create a nullness bug detector that uses the powerful analysis of the Checker Framework and its Nullness Checker, but omits some of its more confusing or expensive features. The goal is to create a fast, easy-to-use bug detector. It would enable users to start small and advance to full verification in the future, rather than having to start out doing full verification.

This could be structured as a new NullnessLight Checker, or as a command-line argument to the current Nullness Checker. Here are some differences from the real Nullness checker:

Each of these behaviors should be controlled by its own command-line argument, as well as being enabled in the NullnessLight Checker.

The implementation may be relatively straightforward, since in most cases the behavior is just to disable some functionality of existing checkers.

Tools such as FindBugs, NullAway, NullnessLight, and the Nullness Checker form a spectrum from easy-to-use bug detectors to sound verification. NullnessLight represents a new point in the design space. It will be interesting to compare these checkers:

Uber's NullAway tool is also an implementation of this idea (that is, a fast, but incomplete and unsound, nullness checker). NullAway doesn't let the user specify Java Generics: it assumes that every type parameter is @NonNull. Does Uber's tool provide users a good introduction to the ideas that a user can use to transition to a nullness type system later?

Enhance the toolset

Improving error messages

Compiler writers have come to realize that clarity of error messages is as important as the speed of the executable (1, 2, 3, 4). This is especially true when the language or type system has rich features.

The goal of this project is to improve a compiler's error messages. Here are some distinct challenges:

Java expression parser

A number of type annotations take, as an argument, a Java expression. The representation for these (the JavaExpression class) is a hack. The goal of this project is to remove it.

The JavaExpression class represents an AST. There is no need for the Checker Framework to define its own AST when the JavaParser AST already exists and is maintained. In fact, JavaExpressionParseUtil uses JavaParser, but needlessly converts a JavaParser Expression into a JavaExpression.

The goals for the project include:

Direct replacement of the classes is not possible, or we would have done it already. For example, JavaExpression contains some methods that JavaParser lacks, such as isUnassignableByOtherCode. As a first step before doing the tasks listed above, you may want to convert these methods from instance methods of JavaExpression into static methods in JavaExpressions, making JavaExpression more like a standard AST that can be replaced by JavaParser classes. You also need to decide how to store the type field of JavaExpression, when JavaExpression is eliminated. An alternate design (or a partial step in the refactoring process) would be to retain the JavaExpression class, but make it a thin wrapper around JavaParser classes that do most of the real work.

Another aspect of this project is fixing the issues that are labeled "JavaExpression".

Dataflow enhancements

The Checker Framework's dataflow framework (manual here) implements flow-sensitive type refinement (local type inference) and other features. It is used in the Checker Framework and also in Error Prone, NullAway, and elsewhere.

There are a number of open issues — both bugs and feature requests — related to the dataflow framework. The goal of this project is to address as many of those issues as possible, which will directly improve all the tools that use it.

Purity (side effect) analysis

A program analysis technique makes estimates about the current values of expressions. When a method call occurs, the analysis has to throw away most of its estimates, because the method call might change any variable. If the method is known to have no side effects, then the analysis doesn't need to throw away its estimates, and the analysis is more precise.

For example, the Checker Framework unsoundly trusts but does not check purity annotations. This makes the system vulnerable to programmer mistakes when writing annotations. The Checker Framework contains a sound checker for immutability annotations, but it suffers too many false positive warnings and thus is not usable. A better checker is necessary. It will also incorporate aspects of an escape analysis.

Choosing an algorithm from the literature is the best choice, but there still might be research work to do: in the past, when implementing algorithms from research papers, we have sometimes found that they did not work as well as claimed, and we have had to enhance them. One challenge is that any technique used by pluggable type-checking to verify immutability must be modular, but many side effect analyses require examining the whole program. The system should require few or no method annotations within method bodies. I'm not sure whether such a system already exists or we need to design a new one.

Perhaps one of these existing side effect analyses could be used: Soot, Geffken.

Javadoc support

Currently, type annotations are only displayed in Javadoc if they are explicitly written by the programmer. However, the Checker Framework provides flexible defaulting mechanisms, reducing the annotation overhead. This project will integrate the Checker Framework defaulting phase with Javadoc, showing the signatures after applying defaulting rules.

There are other type-annotation-related improvements to Javadoc that can be explored, e.g. using JavaScript to show or hide only the type annotations currently of interest.