Incorrect nullablility at PlayerMoveEvent.getTo()

[Brokkonaut]

Expected behavior

PlayerMoveEvent has subclasses like PlayerTeleportEvent and PlayerPortalEvent where getTo() can return null, so PlayerMoveEvent.getTo() must be nullable.

https://github.com/PaperMC/Paper/blob/master/patches/api/0176-Fix-Spigot-annotation-mistakes.patch#L473

Observed/Actual behavior

is not

Steps/models to reproduce

Create a handler for a PlayerPortalEvent, check if getTo() returns null and get a warning

Plugin and Datapack List

no

Paper version

yes

Other

No response

[electronicboy]

last I recall we looked into this, to should NEVER be null, and literally just looked like a broken side-effect of a borked patch?

[Brokkonaut]

I am not sure, but I got some reports about NPEs in the past in one of my plugins when it did no null check there. At least other plugins could create some PlayerTeleportEvent with a null target, because in the constructor it is marked as nullable (why ever they should do that).

[Machine-Maker]

So PlayerPortalEvent#getTo isn't null ever from server use. The constructor param is marked as nullable, but event constructor's aren't API, so that doesn't really matter. PlayerTeleportEvent#getTo does return null sometime. Is a solution to just override getTo in PlayerTeleportEvent and mark it as Nullable? Cause PlayerMoveEvent#getTo isn't nullable when its just a PlayerMoveEvent. In some sense, its not correct to think of these in a hierarchy since they all have separate HandlerList, meaning they can't be listened to by the same listener.