Forward kompatybilny Java 6 procesor adnotacji i SupportedSourceVersion

Question

Staram się Java 7 dla jednego projektu i uzyskanie ostrzeżenia z procesorami adnotacji (Bindgen i Hibernate JPA modelgen) tego rodzaju:

warning: Supported source version 'RELEASE_6' from annotation processor 'org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor' less than -source '1.7' 

jest to spowodowane przez @SupportedSourceVersion(SourceVersion.RELEASE_6) adnotacja na klasach procesorów adnotacji. Ponieważ są one kompilowane przy użyciu środowiska Java 6, najwyższą dostępną dla nich wartością jest SourceVersion: RELEASE_6. Wersja Java 7 w wersji SourceVersion wprowadza RELEASE_7.

Moje pytania: W jaki sposób procesory adnotacji powinny obsługiwać zgodność z wcześniejszymi wersjami? Czy będą musiały być oddzielne wersje binarne jdk6 i jdk7? Czy nie rozumiem tutaj czegoś innego?

ja tylko znaleźć następujące informacje dotyczące tego dotyczą:

Querdydsl bug report który korzystał

@Override 
public SourceVersion getSupportedSourceVersion() { 
    return SourceVersion.latest(); 
} 

Oracle blog w którym commentor zaleca nośnej najnowsza wersja źródło

Answer 1

Forward kompatybilność jest obsługiwany przez przetwarzanie nieznanym języku konstruuje odpowiednio, na przykład poprzez implementację ElementVisitor.visitUnknown.

Jest inna pozycja we wspomnianym Oracle blog, co sugeruje dwie zasady dotyczące kompatybilności przodu:

• Napisz procesora do pracy jedynie z bieżącej wersji językowej.
• Napisz procesor, aby poradzić sobie z nieznanymi przyszłymi konstrukcjami.

Drugi odbywa się poprzez zwrot SourceVersion.latest() jak już zamieszczonych w pytaniu.

Myślę, że w większości przypadków można to zrobić, gdy masz pewność, że dodatkowe elementy językowe niczego nie zepsują. Oczywiście nie powinieneś zakładać, że wszystko będzie dobrze, nawet w nowszych wersjach, powinieneś przetestować to również.

---

Ok, myślę przetwarzanie nieznany język konstruuje odpowiednio brzmi trochę niejasne, więc oto kilka przykładów.

Załóżmy, że masz procesor, który sprawdza niestandardowy typ adnotacji na znanych konstrukcjach językowych (np. Adnotacje na klasie) i tworzy prostą dokumentację tego, co znalazł. Prawdopodobnie można założyć, że będzie działać również w nowszych wersjach. Ograniczenie go do konkretnej wersji nie byłoby w moim przekonaniu dobrą decyzją.

Załóżmy, że masz procesor, który sprawdza każdy element, który może znaleźć i analizuje strukturę kodu, aby wygenerować z niego wykres. Może pojawić się problem z nowszymi wersjami. Być może uda ci się jakoś poradzić sobie z nieznanymi konstruktami językowymi (na przykład dodając do wykresu węzeł nieznany), ale tylko zrób to, jeśli ma to sens - i czy to jest warte problemów.Jeśli procesor po prostu nie byłby przydatny w konfrontacji z czymś nieznanym, powinien prawdopodobnie trzymać się konkretnej wersji java.

Bez względu na zastosowane zasady najlepszym sposobem, moim zdaniem, byłoby monitorowanie nadchodzących zmian w języku i aktualizacja odpowiednio procesora. Na przykład w Java 7, project coin wprowadzono kilka nowych funkcji językowych, które najprawdopodobniej nie są widoczne dla procesora. Z drugiej strony Java 8 ma nowe konstrukcje, które wpływają na przetwarzanie, na przykład type annotations. Nowe funkcje językowe nie zdarzają się jednak często, więc istnieje duża szansa, że ​​od dawna nie trzeba niczego zmieniać.