Enable NRT for Java.Interop.dll #554
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add `#nullable enable` for: * `JavaArray` * `JavaException` * `JavaObject` * `JavaObjectArray` * `JavaPeerableExtensions` * `JavaPrimitiveArrays` * `JniFieldInfo` * `JniMarshal`
Notable change: move away from `ConcurrentDictionary` to `lock` + `Dictionary`, because `ConcurrentDictionary.TryUpdate()` didn't support passing `null` as a new value. To do so, we'd have to move to `ConcurrentDictionary<IntPtr, JniRuntime?>`, which would alter the type of `Runtime.Values`, and change other things.
Of note is that we no longer null out various members in `Dispose()` and instead we call `.Clear()`. This was easier than making everything nullable, and the `Dispose()` codepath really shouldn't ever be invoked anyway....
They support `null` as an input w/o throwing an exception...
Enable nullability for *everything*!
… can reference it.
jonpryor
pushed a commit
that referenced
this pull request
Feb 6, 2020
C# 8 introduced [Nullable Reference Types][0], which allows reuse of
the `nullable_type` grammar in which a `?` suffix on a type indicates
that the value may be null -- which previously could only be placed
on value types -- so that it can be placed onto reference types.
As part of this C# change, within an `enabled` [nullable context][1],
values of reference types such as `string` are *not null* by default.
`string?` would need to be used to indicate that the value may be
`null`.
This change presents a potentially significant *semantic* change,
particularly if `-warnaserror` is used, as source code which
previously allowed `null` values can now elicit C# *warnings* if code
flow analysis/etc. indicates that a non-nullable value may be null.
Enable Nullable Reference Type support for `Java.Interop.dll`:
* Set `$(Nullable)`=enable, so that nullable reference types are
enabled project wide.
* Perform the *minimal* review of the current API to indicate that
certain parameters or return types may accept or return `null`
values.
* Use [additional custom attributes][2] to further "tighten" the
semantics we're trying to describe. In particular,
*type parameters* are generally *non-null*, so if a method
(1) has a return value which is a type parameter, and (2) the
value returned may be null, then the method should be annotated
with a [`MaybeNullAttribute`][3] to indicate that the value could
be null even though the type appears to forbid it.
* Add a `NullableAttributes.cs` file so that we can use the
additional custom attributes, as these types may not be present
in the BCL that we're building against.
`INTERNAL_NULLABLE_ATTRIBUTES` is added to `$(DefineConstants)`
so that these types are `internal` to `Java.Interop.dll`.
* Update `JniRuntime` to move away from `ConcurrentDictionary` to
`lock` + `Dictionary`, because `ConcurrentDictionary.TryUpdate()`
didn't support passing `null` as a new value. To do so, we'd have
to move to `ConcurrentDictionary<IntPtr, JniRuntime?>`, which would
alter the type of `Runtime.Values`, and change other things.
* Update `JniPeerMembers` so that we no longer `null` out various
members in `JniPeerMembers.Dispose()` and we instead call
`InstanceFields.Clear()`. This was easier than making everything
nullable, and the `Dispose()` codepath really shouldn't ever be
invoked anyway....
After all this, there are two remaining nullable-reference type
warnings produced by `Java.Interop.csproj`:
src\Java.Interop\Java.Interop\JniRuntime.JniValueManager.cs(399,13): Warning CS8601: Possible null reference assignment.
src\Java.Interop\Java.Interop\JniRuntime.JniValueManager.cs(476,13): Warning CS8601: Possible null reference assignment.
We currently do not know why this CS8601 is being emitted, and will
need to investigate further.
Additionally:
* Bump to .NET Core 3.1.x which supports nullable reference types.
* Install a newer `boots` tool which supports .Net Core 3.1.
[0]: https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references
[1]: https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references#nullable-contexts
[2]: https://docs.microsoft.com/en-us/dotnet/csharp/nullable-attributes#specify-post-conditions-maybenull-and-notnull
[3]: https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.codeanalysis.maybenullattribute?view=netcore-3.1
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds Nullable Reference Types metadata to Java.Interop.dll.