Ми можемо зробити це за допомогою анотацій!
Щоб викликати помилку, використовуйте, Messagerщоб надіслати повідомлення за допомогою Diagnostic.Kind.ERROR. Короткий приклад:
processingEnv.getMessager().printMessage(
Diagnostic.Kind.ERROR, "Something happened!", element);
Ось досить проста анотація, яку я написав лише для перевірки цього.
Ця @Markerанотація вказує, що ціль є інтерфейсом маркера:
package marker;
import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface Marker {
}
І процесор анотацій викликає помилку, якщо це не так:
package marker;
import javax.annotation.processing.*;
import javax.lang.model.*;
import javax.lang.model.element.*;
import javax.lang.model.type.*;
import javax.lang.model.util.*;
import javax.tools.Diagnostic;
import java.util.Set;
@SupportedAnnotationTypes("marker.Marker")
@SupportedSourceVersion(SourceVersion.RELEASE_6)
public final class MarkerProcessor extends AbstractProcessor {
private void causeError(String message, Element e) {
processingEnv.getMessager()
.printMessage(Diagnostic.Kind.ERROR, message, e);
}
private void causeError(
Element subtype, Element supertype, Element method) {
String message;
if (subtype == supertype) {
message = String.format(
"@Marker target %s declares a method %s",
subtype, method);
} else {
message = String.format(
"@Marker target %s has a superinterface " +
"%s which declares a method %s",
subtype, supertype, method);
}
causeError(message, subtype);
}
@Override
public boolean process(
Set<? extends TypeElement> annotations,
RoundEnvironment roundEnv) {
Elements elementUtils = processingEnv.getElementUtils();
boolean processMarker = annotations.contains(
elementUtils.getTypeElement(Marker.class.getName()));
if (!processMarker)
return false;
for (Element e : roundEnv.getElementsAnnotatedWith(Marker.class)) {
ElementKind kind = e.getKind();
if (kind != ElementKind.INTERFACE) {
causeError(String.format(
"target of @Marker %s is not an interface", e), e);
continue;
}
if (kind == ElementKind.ANNOTATION_TYPE) {
causeError(String.format(
"target of @Marker %s is an annotation", e), e);
continue;
}
ensureNoMethodsDeclared(e, e);
}
return true;
}
private void ensureNoMethodsDeclared(
Element subtype, Element supertype) {
TypeElement type = (TypeElement) supertype;
for (Element member : type.getEnclosedElements()) {
if (member.getKind() != ElementKind.METHOD)
continue;
if (member.getModifiers().contains(Modifier.STATIC))
continue;
causeError(subtype, supertype, member);
}
Types typeUtils = processingEnv.getTypeUtils();
for (TypeMirror face : type.getInterfaces()) {
ensureNoMethodsDeclared(subtype, typeUtils.asElement(face));
}
}
}
Наприклад, це правильне використання @Marker:
Але це використання @Markerпризведе до помилки компілятора:
Ось допис у блозі, який я знайшов дуже корисним для початку роботи з цієї теми:
Невелике зауваження: на що вказує коментатор нижче, це те, що через MarkerProcessorпосилання Marker.classвін має залежність від часу компіляції. Я написав наведений вище приклад з припущенням, що обидва класи працюватимуть в одному файлі JAR (скажімо, marker.jar), але це не завжди можливо.
Наприклад, припустимо, що існує додаток JAR із такими класами:
com.acme.app.Main
com.acme.app.@Ann
com.acme.app.AnnotatedTypeA (uses @Ann)
com.acme.app.AnnotatedTypeB (uses @Ann)
Тоді процесор for @Annіснує в окремому JAR, який використовується під час компіляції JAR програми:
com.acme.proc.AnnProcessor (processes @Ann)
У цьому випадку AnnProcessorне вдалося би безпосередньо посилатися на тип @Ann, оскільки це створило б циклічну залежність JAR. Він міг би посилатися лише @Annна Stringім'я або TypeElement/ TypeMirror.
