Checker Framework
jspecify
Our great sponsors
Checker Framework | jspecify | |
---|---|---|
11 | 11 | |
976 | 411 | |
0.6% | 3.9% | |
9.7 | 8.1 | |
7 days ago | 4 days ago | |
Java | Java | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Checker Framework
- @Nullable et @NonNull
-
Too Dangerous for C++
It is interesting! I experimented with creating a bad borrow checker for Java using annotations from
https://checkerframework.org/
It supports some level of substructural types using must-call annotations,
https://checkerframework.org/manual/#resource-leak-checker
-
JEP 457: Class-File API for Parsing, generating, transforming
Lombok is not a compiler extension. Compiler extensions, aka annotation processors, are offered only specific capabilities that ensure that they preserve the Java language specification. Particularly, code that compiles successfully with an extension also compiles without it (perhaps requiring other classes to be available) and it compiles down to the same bytecode. Annotation processors are used to implement pluggable type systems (e.g. https://checkerframework.org) or to generate other classes (e.g. https://immutables.github.io/).
Unlike compiler extensions, Lombok compiles source files that do not conform to the Java language specification. Lombok is an alternative Java Platform language, like Clojure or Kotlin or Scala, except that it's a superset of the Java language. However, rather than forking `javac` source code and modifying it to compile Lombok source files, the Lombok compiler modifies `javac`'s operation by hacking into its internals and modifying them as it runs to compile Lombok sources rather than Java sources.
Having alternative Java Platform languages is perfectly fine. The problem with Lombok is that it doesn't present itself as such but as a library or a compiler extension even though it violates the Java language specification in ways that compiler extensions are forbidden from doing.
-
I introduced Rust at work
And then I found (thanks Oracle), https://checkerframework.org/ zomg, this thing is awesome. Pluggable Type Systems!
- Checker Framework - Pluggable type systems for Java
-
Don’t call it a comeback: Why Java is still champ
Java should adopt something like the Checker Framework Nullness Checker in its first-party tooling.
https://github.com/typetools/checker-framework
-
Why Java Doesn't Support Multiple Inheritance
And modern (real, non-android) Java via project amber and so on has gone more and more quasi functional with its immutability and sealed and record types for effective sum types, as well as its pretty cool type-use annotation extensible static type checks.
-
JSpecify: Express specifications (initially, just nullness properties) in a machine-readable way
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.
-
calling Format() on a time struct in a golang program changes the default Location's timezone information in the rest of the program
NullAway or the Checker Framework should greatly help eliminate the issue. Also, when Java gets value types you should be able to define your own non nullable value types and use them safely.
-
Java Annotations
There are a lot of existing libraries for type checking modules. For example the Checker Framework created by University of Washington. This framework includes a NonNull module, as well as regular expression module and a mutex lock module. See this for more information.
jspecify
-
Java, null, and JSpecify [video link]
There's also a fair amount of content to explore starting at jspecify.org.
-
I'm not a Java dev but I'm using it in AoC this year
With some projects like https://github.com/jspecify/jspecify you can say your code is @NullMarked, meaning all nullable fields are explicitly marked with @Nullable. That being ubiquitous is...some point in the future.
-
Design document on nullability and value types (Brian Goetz)
Issue about Void
-
Java might eventually get null-restricted types
Details are being worked out in JSpecify [issue 79](https://github.com/jspecify/jspecify/issues/79). At present it is thought that we can have a 1.0 without it; that could still change. Please feel free to join the conversation.
- How to go about writing a library?
-
Java records make Google's AutoValue mostly obsolete
Coincidentally that's my current project -- sort of. We need to stay with an annotation-based approach for a bit longer but we think there's a path. http://jspecify.org
-
JSpecify: Express specifications (initially, just nullness properties) in a machine-readable way
Well, within a @NullMarked context you already don't have to annotate non-nullable types. You probably want a warning when someone forms a @Nullable type from that class, and I've just filed #228 about that.
What are some alternatives?
Daikon - Dynamic detection of likely invariants
KEEP - Kotlin Evolution and Enhancement Process
OpenJML - This is the primary repository for the source code of the OpenJML project. The source code is licensed under GPLv2 because it derives from OpenJDK which is so licensed. The active issues list for OpenJML development is here and the wiki contains information relevant to development. Public documentation for users is at the project website:
jOOQ - jOOQ is the best way to write SQL in Java
CATG - a concolic testing engine for Java
Lombok - Very spicy additions to the Java programming language.
JMLOK 2.0 - Tool for detecting and classifying nonconformances in Java/JML projects.
Error Prone - Catch common Java mistakes as compile-time errors
jCUTE - Java Concolic Unit Testing Engine
PMD - An extensible multilanguage static code analyzer.
eclipse-null-eea-augments - Eclipse External null Annotations (EEA) repository
Auto - A collection of source code generators for Java.