jspecify: Address the "`findViewById` problem" (generally nullable, but in *common* specific cases not) [working decision: no]
We’ve discussed using @NullUnspecified as a way of saying something like “a smarter tool would be able to tell you when this is safe” – or just “this method is used commonly enough that some users/owners are unwilling to tolerate null checks on every call size.” See this earlier discussion from when we discussed using a @LessEnforced annotation for this and this even earlier discussion.
There are a number of places that this could be useful. Rather than dumping these into #32 (as I did recently), I’ll start a new bug with a list, carrying over items from past discussions:
Possible usages for @NullnessUnspecified on return types:
Map.getActivity.findViewById(rough stats on how often callers perform a null check on the result)Context.getSystemServiceFragment.getContextThrowable.getCauseResourceLoader.getClassLoaderThread.getUncaughtExceptionHandlerHttpMethod.resolveDateTimeFormatterFactoryBean.getObjectMap.Entry.getValue: technically “undefined” if the entry has been removed, but some implementations returnnullin that case. Checker Framework leaves it returningV, but we could switch to@NullUnspecified Vif we wanted to be paranoid.Matcher.group(int)Injector.getInstance()- various reflection APIs
Possible usages for @NullnessUnspecified on parameter types:
Joiner.joinMoreObjects.firstNonNull? (Or maybe we’d consider this likecheckNotNull, for which we might allownullinputs that might result in aNullPointerException?)Collection.contains?requireNonNull/checkNotNull?- various reflection APIs
Another category of use cases is @PolyNull, whose status is up in the air. I’ve compiled a list of @PolyNull methods.
(I got to wondering if an evil way to support @PolyNull without @PolyNull would be to allow stubs to contain 2 versions of a method – so one could include @Nullable and the other not. This might work, but it would probably require special rules, and anyway, it would require stub files for a library, while we want code to be annotated inline – and we especially wouldn’t want it to be mostly annotated inline but with magic elsewhere.)
About this issue
- Original URL
- State: open
- Created 5 years ago
- Comments: 25 (2 by maintainers)
I want to sort of “insist” 😃 that we please retitle and reframe this issue. I think we need to remember very solidly that:
If we extend the type system to account for null inclusion/exclusion, we’ll have done a lot of good.
That will be quite hard enough to get done as it is.
These cases listed above, as types, are all nullable, plain and simple.
We always take as granted that our annotations are one source of information that a nullness analyzer will consult when making its decisions of what to report and how. There is nothing stopping it from having additional smarts that cover the nuances of the cases listed above. Those smarts might depend on custom annotations. Those annotations might use our
@Impliesif we provide it. Or they might not.Every time a user voluntarily sticks with unspecified, or makes their own annotation @Imply unspecified instead of nullable, I will shed a tear, because I think this is wrong, but what can you do? That annotation represents the withholding of all information. If they don’t like what their tools are doing with the information, they’re allowed to withhold it.
I want to push back on the idea I’ve been hearing that there are “kinds of nullness that are too complex for our annotations to be able to express”. I think that’s not the right mindset. A (non-type-variable) type usage is either nullable or not (well, or legitimately unspecified), just like an integral type is either int or long. The type must include the union of all values that ever might come through. Now there can be any manner of additional knowledge someone could code up about which values of that type it can actually take on in real life and in which circumstances. Maybe someone will even bring “refinement types” to Java (shudder). But this really shouldn’t be our concern in this project.
Post-1.0, however far off that is, sure, we could always talk about this again.
Can everyone live with this? If there’s an objection that’s sticking in your mind that won’t go away easily, then sure, let’s have that out.
Yes, we don’t annotate
Matcher.groupmethods as Nullable. A sophisticated analysis could be done to check whether the original pattern contains alternating groups, but this is out of the scope of our project and cannot be always determined statically. I agree that the problem is not substantially different fromMap.get.