JSpecify: Express specifications (initially, just nullness properties) in a machine-readable way

This page summarizes the projects mentioned and recommended in the original post on reddit.com/r/java

Our great sponsors
  • Mergify - Automate your Pull Request with Mergify
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
  • jspecify

    An artifact of fully-specified annotations to power static-analysis checks, beginning with nullness analysis.

    Ideally that @PolyNull annotation (in a checker-specific jar) will mark itself with @Implies(Nullable.class) (those two classes being from the JSpecify jar; @Implies ks discussed here). This accomplishes something cool: if Library X decides to adopt that @PolyNull, then a caller whose checker supports it will be happy, but also a caller whose checker supports only vanilla JSpecify 1.0 will at least degrade in the best way available to it: treating those types as nullable and only losing some information. This seems reasonable to me.

  • jOOQ

    jOOQ is the best way to write SQL in Java

    They are not yet annotated. It's much more work to annotate type variables than to annotate method return types. But it will be done eventually, see task here: https://github.com/jOOQ/jOOQ/issues/10780

  • Mergify

    Automate your Pull Request with Mergify. Mergify is the most powerful merge queue tool that offers speculative checks, batch merges, and multiple queueing options. Coordinated with any CI and fully integrated to GitHub. Get started or request a demo!

  • Lombok

    Very spicy additions to the Java programming language.

    There are a sum total of 11 different nullity libraries listed in Lombok's null support system. I made that list a while ago but at the time they were all used in some amount, and I'm sure that list isn't even exhaustive. So when I started this post with the XKCD comic that goes from 14 to 15? That wasn't hyperbole.

  • Checker Framework

    Pluggable type-checking for Java

    Checkerframework - a really academic take, and as one might expect from such a thing, backed by tons of papers and analysed to perfection. Specifically, this is the only framework I'm aware of that realizes nullity is a little more complicated than just a boolean yes-or-no; just like generics actually have 4 flavours for any given type: List, List, List, and List are all 4 important and unique, and nullity is no different. Specifically, it can occur that you want to write a method that ought to accept both lists of nullable strings as well as list of nonnull strings, and needs to 'convey' this nullity again on its output. You can either attempt to lift along the existing generics system in java which I think is your intent, but it's not actually all that easy to do this. After all, T extends @Nullable Number super @NonNull Number, or whatnot, isn't legal java. So you.. really just can't do that. Checker Framework solves this problem by introducing the @PolyNull annotation, which still isn't perfect but covers almost all real world use cases you can think of. I'm missing any acknowledgement in your documentation. An oversight, or, something you hadn't thought of yet? You're in good company: Both eclipse and intellij's engineers, when I asked them about it, just hadn't realized it was a thing. Point is: If you think the primary problem with e.g. eclipse's and intellij's take is that they lack academic rigour - checkerframework has you beat.

  • KEEP

    Kotlin Evolution and Enhancement Process

    I'm aware that kotlin decided against this in kotlin itself, see https://github.com/Kotlin/KEEP/issues/82.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts