[JAVA-2641] Add JSR-305-compatible NonNull annotations to the driver API Created: 18/Oct/17 Updated: 29/Oct/23 Resolved: 20/Mar/18 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | API |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.0 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Jeffrey Yemin | Assignee: | Jeffrey Yemin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Epic Link: | Kotlin Support | ||||||||||||||||||||
| Description |
|
Annotating the public API with NonNull annotations will allow tools like IntelliJ and other JVM languages like Kotlin to enforce constraints on application code that uses the driver. See for an example the recent support for null-safety added to Spring Framework 5.0 here. A couple of strange things about JSR-305 that need to be considered:
|
| Comments |
| Comment by Githook User [ 20/Mar/18 ] |
|
Author: {'email': 'ross.lawley@gmail.com', 'name': 'Ross Lawley', 'username': 'rozza'}Message: Moved JSR-305 compatible annotation to driver-core
|
| Comment by Githook User [ 20/Mar/18 ] |
|
Author: {'email': 'jeff.yemin@10gen.com', 'name': 'Jeff Yemin', 'username': 'jyemin'}Message: |
| Comment by Githook User [ 20/Mar/18 ] |
|
Author: {'email': 'jeff.yemin@10gen.com', 'name': 'Jeff Yemin', 'username': 'jyemin'}Message: |
| Comment by Githook User [ 19/Mar/18 ] |
|
Author: {'email': 'jeff.yemin@10gen.com', 'name': 'Jeff Yemin', 'username': 'jyemin'}Message: |
| Comment by Githook User [ 19/Mar/18 ] |
|
Author: {'email': 'jeff.yemin@10gen.com', 'name': 'Jeff Yemin', 'username': 'jyemin'}Message: |
| Comment by Githook User [ 19/Mar/18 ] |
|
Author: {'email': 'jeff.yemin@10gen.com', 'name': 'Jeff Yemin', 'username': 'jyemin'}Message: |
| Comment by Githook User [ 19/Mar/18 ] |
|
Author: {'email': 'jeff.yemin@10gen.com', 'name': 'Jeff Yemin', 'username': 'jyemin'}Message: |
| Comment by Githook User [ 19/Mar/18 ] |
|
Author: {'email': 'jeff.yemin@10gen.com', 'name': 'Jeff Yemin', 'username': 'jyemin'}Message: |
| Comment by Githook User [ 19/Mar/18 ] |
|
Author: {'email': 'jeff.yemin@10gen.com', 'name': 'Jeff Yemin', 'username': 'jyemin'}Message: |
| Comment by Mark Paluch [ 27/Dec/17 ] |
|
Spring Framework's (Non)Nullability annotations are intended primarily to assist developers during development time within their IDE. Our annotations are annotated with proper JSR-305 annotations to comply with JSR-305's ideas. JSR-305 is not required to be on the classpath during development-time/compile-time/runtime of user-code. Our public API defaults to non-null by annotating packages with @NonNullApi. Exceptions to non-nullability defaults (parameters, method return, fields) are annotated with @Nullable. @NonNull is used for rather punctual non-nullability indications without requiring to alter a whole package. We have additional runtime support based on our annotations to allow/reject null values in method arguments and return values on controller and repository API if user-code is annotated using Spring Framework's annotations. If JSR-305 annotations are on the class-path, then we can leverage these, too (e.g. user-defined meta-annotations), but that's totally optional. We're expressing nullability constraints using Spring Framework's annotations on our public API. We're using Lombok's @Nonnull in combination with @RequiredArgsConstructor to generate non-null checks. |
| Comment by Jeffrey Yemin [ 27/Dec/17 ] |
|
mpaluch@paluch.biz cstrobl Can either of you elaborate on the thinking behind taking the JSR-305 dependency in the Spring Framework, given the issues with the Java 9 module system (and perhaps OSGi)? And why are the nullability-related Lombok annotations used in some places, but quite sparingly? Was any thought given to more pervasive use of run-time null checks using code generation, as Lombok supports with its annotation processor? |
| Comment by Jeffrey Yemin [ 08/Dec/17 ] |
|
A few additional notes:
So one option is to emulate Spring's technique, which centralizes the JSR-305 references to just a few annotations. |