Please provide following information which will help us to investigate this further,

• What is the desired behavior of the feature? (Be specific!)

• If relevant, why are current approaches or workarounds insufficient?

• If relevant, what new use cases will this feature enable?

What is the desired behavior of the feature? (Be specific!)

When I'm writing Java code for my Android app, I want to be able to use the Android IntDefs in my generics. Like

List<@ColorInt Integer> mColors;

Right now this doesn't compile. I get the following error

Example.java:937: error: annotation @ColorInt not applicable in this type context

If relevant, why are current approaches or workarounds insufficient?

I'm not aware of a work around to achieve what I want. And a work around would benefit all Android developers less.

If relevant, what new use cases will this feature enable?

Better static analysis to prevent bugs in Android apps.

Julia, do we have a record of the discussion around JSpecify migration versus modifying the existing annotations? IIRC we had very good reasons not to add TYPE_USE or replace the existing targets with TYPE_USE.

Found your doc. For removing existing targets,

Removing other targets

Removing the non-type annotation targets from the nullability annotations is not planned for this project. Removing the existing targets would be a much more disruptive change for clients as it would invalidate existing usages (for instance @NonNull Map.Entry<K, V> would cause a compilation error; Map.@NonNull Entry<K, V> is the correct usage).

Before other targets are removed, they should be “deprecated”, but Java does not have a mechanism for deprecating annotation targets. This might be done in the future through a bundled lint check, but because Android lint does not currently support type-use annotations, this would currently be difficult to implement.

And for adding, there were issues for arrays -- and, generally, it's not a great developer experience when the annotation can just be put anywhere and Lint has to deal with interpreting what it's supposed to mean. From your doc again,

Handling Arrays

For the most part adding TYPE_USE to the nullability annotations does not meaningfully change the existing usages: the annotation now also applies to the type in addition to the method/parameter, but that’s what it was always intended to mean. However, adding the type-use target causes issues for arrays.

In Java, a type-use annotation preceding an array applies to the component type of the array, not the array itself. However, because the annotations will be both type-use and method/parameter-use, a leading annotation also applies to the method/parameter.

So I think the best path forward here would, unfortunately, be adding new annotations.

(But let's only do this if we also update the lint analysis to handle it!)

I think the concerns in comment #5 aren't as significant for IntDef annotations such ColorInt as they were for nullability.

Nullness annotations are used on definitions of any type, but that isn't true for IntDefs, which are only supposed to be applied to definitions with type int or int[] (or Integer?). The problematic case for nullness annotations, usage before a qualified type like @NonNull Map.Entry<K, V>, shouldn't be a problem for IntDefs unless the annotations were being used incorrectly already.

For the array case, the positioning rules for type-use annotations work here. For instance in @ColorInt int[], if @ColorInt were type-use it would apply to the int type, which is correct. If we left the other annotation targets, it would apply to the element as well, but I don't think that would be a problem since the lint rules are already set up to recognize that.

I'd want to test a bit to confirm there aren't other issues, and agreed with comment #6: we would first need to update the relevant lint checks to handle type-use annotations (I previously just updated the nullness lint checks to recognize type-use annotations).