A DESCRIPTION OF THE REQUEST :
When a project defines an annotation processor it is customary to mark it e.g.

@SupportedSourceVersion(SourceVersion.RELEASE_6)

if JDK 6 is the minimum version needed to build and run. But then if someone uses the processor on a project using -source 7, they will get a warning even when the processor is working fine:

warning: Supported source version 'RELEASE_6' from annotation processor '...' less than -source '1.7'

In principle it is right to issue a warning, since it is conceivable that the processor actually cannot handle some JDK 7 language construct. (I cannot come up with an actual example in this case, since the JDK 7 changes were mainly at the expression level, but presumably this would be more plausible for the 7 -> 8 transition.)

Even if the author of the processor knows that RELEASE_7 is supported, there is no way to indicate this when JDK 6 is the baseline.

Unfortunately in the normal case when the processor works fine on JDK 7 and both its author and its user know this, there is no way to disable the warning. At a minimum, this should be in a -Xlint category so it can be cleanly suppressed.

Motivating issues:
https://netbeans.org/bugzilla/show_bug.cgi?id=210286
https://github.com/kohsuke/metainf-services/issues/3

JUSTIFICATION :
Unable to produce warning-free compilations when using -source 7 on projects making use of annotation processors built for JDK 6+.


CUSTOMER SUBMITTED WORKAROUND :
1. Use SourceVersion.valueOf("RELEASE_7") and catch IllegalArgumentException - ick.

2. Use SourceVersion.latest() and hope that the processor is never used in a very new language that it actually cannot handle.

3. Prepend the JDK 7 version of JSR 269 APIs to the bootclasspath when building (or only build the processor using JDK 7), and hope that it still works in JDK 6. I have not yet tried this since it seems too onerous, and also makes it hard to avoid accidentally using other JDK 7+ APIs besides RELEASE_7.

4. Document that JDK 7+ javac must be used to run the processor, even for a project using -source 6 built against JDK 6 bootclasspath. Would be fine if common Java build tools could handle this setup easily, e.g. if OpenJDK javac were published in Maven Central, but not practical today.