RFR: 8305250: Unnecessary "unknown enum constant" warning emitted by javac when dependency has optional annotations with enums
Volkan Yazici
vyazici at openjdk.org
Fri Feb 20 14:35:09 UTC 2026
On Thu, 19 Feb 2026 14:22:37 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:
> Consider snippet like:
>
> @UnresolvableAnnotation
> int f1;
> @UnresolvableAnnotation(unresolvable = 0)
> int f2;
> @UnresolvableAnnotation(unresolvable=UnresolvableEnum.A)
> int f3;
>
>
> javac will currently handle the 3 unresolvable aspects completely differently:
> - for `UnresolvableAnnotation`, there is no error, and no warning,
> - for `unresolvable` (attribute), there's no error, and a lint warning bound to `-Xlint:classfile`,
> - for `UnresolvableEnum` (either the enum type, or an enum constant), there's no error, and an unconditional warning.
>
> Note that the attribute method may primarily be unresolvable, because the annotation type is unresolvable.
>
> This appears to cause issues for projects that read classfiles with annotations, but don't have the corresponding annotation API on the classpath.
>
> The proposal herein is twofold:
> - the warning for the `UnresolvableEnum` will now be an `-Xlint:classfile` warning as well, so it will be suppressible. This is for consistency.
> - if the annotation type of an annotation is not resolvable, suppress/ignore all warnings inside that annotation. This is to aid cases where the annotation API is intentionally not on the classpath, which is valid to some degree (to mimic runtime behavior).
>
> Note that if the annotation type is resolvable, than the warnings for the nested elements will continue to be reported. Such cases either means a wrong version of the annotation/enum type was used, or a likely classpath misconfiguration, and hence the warning does not see unwarranted there.
@lahodaj, thanks so much for picking this up. Would you mind giving the community some extra time to evaluate the effects of this change before integrating it, please?
FWIW, I will link certain issues that I know of are affected by this change:
- apache/logging-log4j2/issues/3437
- apache/logging-log4j2/pull/3450
- apache/logging-log4j2/issues/4034
- junit-team/junit-framework/issues/1065
I'm pretty sure there are hundreds of more out there in the wild.
src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 1:
> 1: /*
Copyright year needs to be updated.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29818#issuecomment-3935230641
PR Review Comment: https://git.openjdk.org/jdk/pull/29818#discussion_r2833499185
More information about the compiler-dev
mailing list