IssueTracker

When we fix nullability in Jetpack libraries, it is very painful for clients. Also for us attempting to land in g3.

I think this is a good idea; however, I'm not sure if we'd run into any issues since these are currently synthetic annotations generated by Metalava. It's possible that creating real annotations might conflict with the SDK stubs.

If we do this we need to involve the Kotlin team; this basically introduces an "unenforced nullability warnings" level; they added the hardcoded qualified names for those two classes into the Kotlin compiler. intended for the narrow use case it's there for now; if this were to be broadened into something bigger they should be involved. +jvg

If we use the exact same class names in the androidx.annotation package for the exact same purpose, would we expect to need any work on the Kotlin compiler side?

No, but so far those annotations have been hidden from view (even Android Studio tries hide to hide them, so the AndroidOverrideAnnotationsHandler for example rewrites signatures such that when you override a platform with some of these, you don't see them), and the annotations themselves have package private access so nobody can access them directly. This includes platform code; they cannot directly declare themselves to have the special warning nullcontract; it's only a build time transformation that exposes this. When you said you wanted to expose these annotations for usage by libraries, it sounds like you can now have a situation where libraries start using a special type of nullness annotation which doesn't have the normal guarantees and enforcement normally required by Kotlin. It's true, the Android platform APIs have some special handling for that; I'm just saying that if this is going to be broadened out into more widespread usage, that's something I think the Kotlin team should get to weigh in on, because the current scheme (where they hardcoded our two well known annotation names into the compiler) was agreed upon with a very specific narrow use case.

Do you think it's worth the effort?

This is coming up as the side-effect of a recent Lint Fixit event where we added nullability annotations to a couple hundred APIs. It's a Good Thing (tm) but the fall-out in Kotlin sources is pretty bad, especially for override signature mismatches. There are enough failures in google3 that we've decided to revert the nullability changes for entire library groups.

Maybe there is a better way to address this than using @Recently to give developers a heads-up? Something we can automate?

It seems hard to automate. I think helping with library upgrades would be very valuable. We've done a lot of work to help upgrading AGP itself, but obviously, upgrading libraries is where the real pain is. We've started work on the targetSdkVersion migration assistant, which will help update you from one targetSdkVersion to the next. We could generalize this for libraries too. And making nullness API migration could be one of the things we built into that, where we would simply adjust all the overridden method signatures types to match those inherited from androidx. We don't even need to track which ones have changed recently; if your signature isn't compatible, we know it's from an unlucky earlier guess. Obviously, if your code then goes ahead and does something invalid (e.g. if we switch a parameter from non null to nullable, then your code will no longer compile since you have to add null checks, but that can't be helped (and is probably a good thing).

And making nullness API migration could be one of the things we built into that, where we would simply adjust all the overridden method signatures types to match those inherited from androidx.

Yes, please. Do you want to use this issue to capture that FR, an existing issue, or should I file a new one?