Conversation
docs/topics/jvm/java-interop.md
Outdated
| | `warn` | Reports warnings. | | ||
| | `ignore` | Ignores nullability mismatches. | | ||
|
|
||
| For more information, see the [JSpecify user guide](https://jspecify.dev/docs/user-guide). |
There was a problem hiding this comment.
Maybe move this to just after the annotation list as an info box or something? Having this directly after the kotlinc option might make it confusing as to what "more information" will be available at the link.
There was a problem hiding this comment.
Right, turned it into a tip box
docs/topics/jvm/java-interop.md
Outdated
| You can customize this the severity of JSpecify nullability diagnostics using the following compiler option: | ||
|
|
||
| ```properties | ||
| -Xnullability-annotations=@org.jspecify.annotations:<report-level> |
There was a problem hiding this comment.
There's also a -Xjspecify-annotations=<report-level> option available which is a bit more direct.
There was a problem hiding this comment.
Yeah, let's use it instead
Co-authored-by: Brian Norman <brian@bnorm.com>
daniCsorbaJB
left a comment
daniCsorbaJB
left a comment
There was a problem hiding this comment.
Nice one! 💯 (thank you for adding links as well to some other nullability annotations! 🚀)
I left a couple of suggestions; please let me know what you think.
docs/topics/jvm/java-interop.md
Outdated
| You can specify whether the compiler reports a nullability mismatch based on the information from specific types of | ||
| nullability annotations. Use the compiler option `-Xnullability-annotations=@<package-name>:<report-level>`. | ||
| In the argument, specify the fully qualified nullability annotations package and one of these report levels: | ||
| You can instruct the compiler to report a nullability mismatch based on the information from specific types of |
There was a problem hiding this comment.
Hmm 🤔 What do you think about streamlining this a bit like:
You can configure how the compiler reports nullability mismatches for specific nullability annotations using the following compiler option:
docs/topics/jvm/java-interop.md
Outdated
| * `strict` to report errors. | ||
|
|
||
| See the full list of supported nullability annotations in the | ||
| > [JSpecify](#jspecify-support) is the recommended choice for nullability annotations because it's the only |
There was a problem hiding this comment.
instead of phrasing it as a recommendation, what do you think of just an explanation:
JSpecify is the only supported option that uses strict reporting by default. Use it to enable strict nullability checks without additional configuration.
Or even shorter:
You can use JSpecify to enable strict nullability checks by default.
There was a problem hiding this comment.
It still should be like a recommendation note, rephrased a bit
docs/topics/jvm/java-interop.md
Outdated
| Type variables remain "null-agnostic" until a specific nullable or non-nullable type is provided later. | ||
|
|
||
| * `@NullUnmarked` reverses the effect of `@NullMarked`, making all types within the scope [platform types](#null-safety-and-platform-types) | ||
| again. |
There was a problem hiding this comment.
| again. |
There was a problem hiding this comment.
I think we can remove this.
Co-authored-by: Dániel Csorba <150924204+daniCsorbaJB@users.noreply.github.com>
daniCsorbaJB
left a comment
daniCsorbaJB
left a comment
There was a problem hiding this comment.
Thank you! I left one last suggestion — LGTM! 🚀
| * `strict` to report errors. | ||
|
|
||
| See the full list of supported nullability annotations in the | ||
| > [JSpecify](#jspecify-support) is the only supported flavor that uses `strict` report level by default. |
There was a problem hiding this comment.
| > [JSpecify](#jspecify-support) is the only supported flavor that uses `strict` report level by default. | |
| > [JSpecify](#jspecify-support) is the only supported option that uses `strict` report level by default. |
There was a problem hiding this comment.
The list of packages introduced with 'flavor', so it makes sense to refer to it in the same way
4 participants
No description provided.