Możemy to zrobić za pomocą adnotacji!
Aby zgłosić błąd, użyj, Messageraby wysłać wiadomość z Diagnostic.Kind.ERROR. Krótki przykład:
processingEnv.getMessager().printMessage(
Diagnostic.Kind.ERROR, "Something happened!", element);
Oto dość prosta adnotacja, którą napisałem, żeby to przetestować.
Ta @Markeradnotacja wskazuje, że celem jest interfejs znacznika:
package marker;
import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface Marker {
}
A procesor adnotacji powoduje błąd, jeśli tak nie jest:
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));
}
}
}
Na przykład są to prawidłowe zastosowania @Marker:
Ale te zastosowania @Markerspowodują błąd kompilatora:
Oto post na blogu, który okazał się bardzo pomocny w rozpoczęciu tego tematu:
Mała uwaga: to, na co zwraca uwagę poniższy komentator, to fakt, że z powodu MarkerProcessorodniesień Marker.classma zależność od czasu kompilacji. Powyższy przykład napisałem z założeniem, że obie klasy będą znajdować się w tym samym pliku JAR (powiedzmy marker.jar), ale nie zawsze jest to możliwe.
Na przykład załóżmy, że istnieje plik JAR aplikacji z następującymi klasami:
com.acme.app.Main
com.acme.app.@Ann
com.acme.app.AnnotatedTypeA (uses @Ann)
com.acme.app.AnnotatedTypeB (uses @Ann)
Wówczas procesor dla @Annistnieje w osobnym JAR, który jest używany podczas kompilacji aplikacji JAR:
com.acme.proc.AnnProcessor (processes @Ann)
W takim przypadku AnnProcessornie byłoby możliwe bezpośrednie odwołanie się do typu @Ann, ponieważ spowodowałoby to utworzenie cyklicznej zależności JAR. Byłoby w stanie odwoływać się tylko @Annprzez Stringnazwę lub TypeElement/ TypeMirror.
