Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make enumerate accept @Nullable Thread[] (ditto ThreadGroup). #28

Merged
merged 1 commit into from
Aug 9, 2023

Conversation

cpovirk
Copy link
Collaborator

@cpovirk cpovirk commented Jul 26, 2023

Since the method only writes to the array, it is fine with either a
nullable element type or a non-nullable element type. (I'm operating
under the usual assumption that tools treat arrays as covariant. For
purposes of Checker Framework users who set -AinvariantArrays, we
could consider using @PolyNull instead in eisop.)

This change is prompted by a Kotlin caller that passes an array of
Thread? because Kotlin won't allow an uninitialized array of Thread.
In Java, I would expect most users to allocate an uninitialized array of
[@NonNull] Thread and pass that.

(This is a pretty weird API, though, since it requires you to pass in an
array that you pre-size for the number of threads you expect and so you
might overshoot and end up (I assume; the docs are not clear) with nulls
in the result....)

Since the method only writes to the array, it is fine with either a
nullable element type or a non-nullable element type. (I'm operating
under the usual assumption that tools treat arrays as covariant. For
purposes of Checker Framework users who set `-AinvariantArrays`, we
could consider using `@PolyNull` instead in eisop.)

This change is prompted by a Kotlin caller that passes an array of
`Thread?` because Kotlin won't allow an uninitialized array of `Thread`.
In Java, I would expect most users to allocate an uninitialized array of
`[@nonnull] Thread` and pass that.

(This is a pretty weird API, though, since it requires you to pass in an
array that you pre-size for the number of threads you expect and so you
might overshoot and end up (I assume; the docs are not clear) with nulls
in the result....)
Copy link
Collaborator

@wmdietl wmdietl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, looks good!
Using @PolyNull for EISOP sounds reasonable, too. The javadoc makes it sound like only the non-null threads are written in the array, so any remaining elements should stay untouched. So if an array with only non-null elements is passed in, all elements should stay non-null.

@wmdietl wmdietl assigned cpovirk and unassigned wmdietl Aug 9, 2023
@cpovirk cpovirk merged commit b38d6cc into main Aug 9, 2023
1 check passed
cpovirk added a commit to cpovirk/jdk that referenced this pull request Aug 23, 2023
See jspecify/jdk#28, noting the change from
`@Nullable` to `@PolyNull`.
@wmdietl wmdietl deleted the enumerate branch September 6, 2023 15:54
cpovirk added a commit that referenced this pull request Mar 14, 2024
This matches `ThreadGroup.enumerate`, which `Thread.enumerate` calls.

My reading of #28 is that I'd meant
to cover both classes then, but apparently I didn't.

(For the Checker Framework, we'll use `@PolyNull` instead, as we do for
`ThreadGroup`.)

Fixes #61
cpovirk added a commit that referenced this pull request Mar 15, 2024
This matches `ThreadGroup.enumerate`, which `Thread.enumerate` calls.

My reading of #28 is that I'd meant
to cover both classes then, but apparently I didn't.

(For the Checker Framework, we'll use `@PolyNull` instead, as we do for
`ThreadGroup`.)

Fixes #61
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants