RetentionPolicy.RUNTIME and RetentionPolicy.SOURCE @Asynchronize annotations

[cristcost]

Use two different annotations and have the processor support both of them: One annotation needs to have RetentionPolicy.SOURCE, and be discarded after compilation and generation of asynchronous interface. The other annotation needs to have RetentionPolicy.RUNTIME, so it is kept and available via reflection.

Only the RetentionPolicy.RUNTIME annotation supports the option of annotating generated interface with @AsyncOf \

[tbroyer]

Is that really needed? If the annotation is not available at runtime, reflection on the class will just skip it; no error.

[cristcost]

The motivation is that with RetentionPolicy.RUNTIME, the clients using the interface need to depend on the asynchronize-processor project to resolve the import of the annotation (issue #2 will address partially this but does not eliminate the dependency completely).

With RetentionPolicy.SOURCE, the annotation is discarded and dependency propagation could be avoided. I want the processor to be used in both ways.

Priority is anyhow low for me, but if someone need this I could implement and release it quickly.

[tbroyer]

The motivation is that with RetentionPolicy.RUNTIME, the clients using the interface need to depend on the asynchronize-processor project to resolve the import of the annotation

This is wrong.

Take this class:

import javax.inject.Singleton;

@Deprecated
@Singleton
public class Foo {
  public static void main(String[] args) {
    for (Object annotation : Foo.class.getAnnotations()) {
      System.out.println(annotation.toString());
    }
  }
}

Compile it:

$ javac -cp ~/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar Foo.java

Then run it, with the annotation in the classpath:

$ java -cp ~/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar:. Foo
@java.lang.Deprecated()
@javax.inject.Singleton()

and without:

$ java -cp . Foo
@java.lang.Deprecated()

[cristcost]

Yeah, this is a test I promised myself to do and didn't had time yet, thank you!

But I'm concerned to use annotations with RetentionPolicy.RUNTIME without providing them in the classpath: I cannot exclude that there are conditions where this could be an issue for someone else. In such case, using RetentionPolicy.RUNTIME and RetentionPolicy.SOURCE seems to be semantically correct and could be a possible solution.

Again, this issue has low priority unless someone really need this fix and demonstrate a different case where it is a real issue.

Background: Using a Jar annotated with JaxB inside an Android project, even if the Android project's code does not make use of these annotations, makes Eclipse reports this error:

JaxB annotations are not available in Android platform (and cannot be added as Android deny adding classes in java.* and javax.* packages) but the application still compiles and works.

The error (and it is not just a Warning) is not a Java Error so the project compiles. I have not investigated if it is a false positive reported by Eclipse and allowed by Java specification, in which case it may be removed in future versions of Eclipse. But since then I consider wrong depending on annotation with RetentionPolicy.RUNTIME without providing them in the classpath.

Again thank you for your test ;-)