Our great sponsors
-
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.
-
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
-
InfluxDB
Collect and Analyze Billions of Data Points in Real Time. Manage all types of time series data in a single, purpose-built database. Run at any scale in any environment in the cloud, on-premises, or at the edge.
-
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.
-
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.
-
I'm aware that kotlin decided against this in kotlin itself, see https://github.com/Kotlin/KEEP/issues/82.
-
Mergify
Updating dependencies is time-consuming.. Solutions like Dependabot or Renovate update but don't merge dependencies. You need to do it manually while it could be fully automated! Add a Merge Queue to your workflow and stop caring about PR management & merging. Try Mergify for free.
