[myhau]

What's changed?

JavaxAnnotationMigrationToJakartaAnnotation renamed the whole javax.annotation package. That package is shared with JSR-305 (CheckReturnValue, CheckForNull, ParametersAreNonnullByDefault, Nonnegative, ...), whose annotations don't exist in jakarta.annotation, so migrated code stopped compiling.

Before

import javax.annotation.CheckReturnValue;
import javax.annotation.PostConstruct;

After (main): compilation failure

import jakarta.annotation.CheckReturnValue; // cannot find symbol: class CheckReturnValue, location: package jakarta.annotation
import jakarta.annotation.PostConstruct;

After (this PR)

import jakarta.annotation.PostConstruct;

import javax.annotation.CheckReturnValue;

The recipe now:

• renames the jakarta.annotation-api types by name with ChangeType (Generated, ManagedBean, PostConstruct, PreDestroy, Priority, Resource, Resources, and Nonnull/Nullable as before);
• then runs the package rename in a new ChangeUnresolvedJavaxAnnotationPackage, guarded by DoesNotUseType javax.annotation.*. ChangeType only matches resolved types, so this keeps migrating Java 8 models where these annotations came from the JDK (addApiForUnattributedJdkAnnotation), without touching files that still use a resolved JSR-305 annotation.

Tests

• keepsJsr305Annotations, migratesJsr250AnnotationsNextToJsr305, splitsWildcardImportBetweenJakartaAndJsr305 (import javax.annotation.* used for both), migratesEveryJakartaAnnotationApiType.
• ProvidedJakartaApiScopeTest now uses an import instead of a fully qualified field, since ChangeType shortens fully qualified references.

Known limitations

• An unresolved JSR-250 type in a file that also uses a resolved JSR-305 type stays on javax, because the guard is per file.
• An unresolved JSR-305 type is still renamed, as on main.
• ChangeType can add an import that shadows a same-package class with the same simple name (@javax.annotation.Resource next to a class Resource in the same package). This is a ChangeType issue in rewrite core; a fix is in progress there.

Related

• Fix #457: Refactor javax.annotation to ChangePackage #525: switched to ChangePackage; comments report the JSR-305 breakage, Knut suggested an exceptions option
• Only add jakarta.annotation-api for JSR-250 types, not JSR-305 #1316: the same JSR-250-only approach for the dependency in AddCommonAnnotationsDependencies

[timtebeek]

Maybe I'm misunderstanding, but I don't see this do very much with the precondition making it such that the ChangePackage can't match the same. What's the thinking or use case here?