znaleziono niezgodne typy: wymagane: domyślne wyliczenia w adnotacjach

Question

[javac] C:\ws\galileo\test\Cacheable.java:13: incompatible types 
[javac] found : com.io.CacheType 
[javac] required: com.io.CacheType 
[javac] public CacheType id() default CacheType.COMMON; 

Naprawdę nie dostaję tego. Mam projekt, w którym niestandardowo buduję przechwytywacz buforujący na wiosnę. Jest to po prostu wygląd nazwy pamięci podręcznej, aby wskazywał na EhCache i używa aop-autoproxy do załadowania CacheableAspect (która jest moją interpreterem buforowania). Teraz, gdy używam wartości domyślnej w adnotacji, ANT daje mi poniżej błąd kompilatora. Próbowałem aktualizacji do najnowszej wersji JDK (mam teraz 1.6 16) i ustawienie poziomów źródła/celu w skrypcie ant, ale bez powodzenia. Kiedy usuwam wartość domyślną i wymuszam na wszystkich obszarach, aby określić wartość, kompiluje się ona w mrówce.

Zawsze działał w Eclipse, miałem testy jednostkowe, które działały idealnie z poprzednią wartością domyślną.

Co daje? Próbowałem zbudować projekt (bez sprężyny), który po prostu powtórzył konfigurację za pomocą mrówki i skompilował ją w ant fine (i w eclipse).

który mówi mi, że może to być wiosenny automatyczny serwer proxy? ale dlaczego kompilator nie dałby mi nazwy wygenerowanego typu? GRRRR. jakieś pomysły?

import java.lang.annotation.ElementType; 
import java.lang.annotation.Retention; 
import java.lang.annotation.RetentionPolicy; 
import java.lang.annotation.Target; 

import com.io.CacheType; 

@Retention(RetentionPolicy.RUNTIME) 
@Target({ElementType.METHOD}) 
public @interface Cacheable { 
public CacheType value() default Cachetype.COMMON; 
} 

public enum CacheType { 

COMMON("common"), 
PERSISTENT("persistent"; 

private String cache; 

CacheType(String cache) { 
    this.cache = cache; 
} 

public String cache() { 
    return this.cache; 
} 
} 

Answer 1

nadal obecne w JDK 6u25, ale dodanie pakietu na wartość domyślną załatwia sprawę:

CacheType value() default com.io.CacheType.COMMON; 

Answer 2

Zastanawiam się, czy jest to spowodowane przez zdefiniowanie Cacheable i CacheType w tym samym pliku źródłowego, a następnie importowanie „com.io.CacheType”. To może spowodować, że kompilator uzna, że ​​istnieją dwie klasy o nazwie "com.io.CacheType".

Answer 3

Czy możesz opublikować cały plik źródłowy? Wysłany przez Ciebie kod jest kopiowany/wklejany z różnych plików źródłowych i jest pełen literówek.

Zwykle następuje zawsze powinno wystarczyć, gdy CacheType enum jest w innym pliku źródłowego, trzeba było literówkę w CacheType.COMMON:

public @interface Cacheable { 
public CacheType value() default CacheType.COMMON; 
} 

Answer 4

rzucić okiem tutaj: http://bugs.sun.com/view_bug.do?bug_id=6512707 To może być przyczyną twojego problemu.

Answer 5

Po prostu mała aktualizacja. Podczas gdy moduł do śledzenia błędów pokazuje błąd jako zamknięty i wydaje się, że chce obalić wszelkie nowe otwarcia błędu. Kiedy napotkałem ten błąd w tym przykładzie, obraca się wokół procesora adnotacji czasu kompilacji. Ponieważ retencja to RUNTIME, co oznacza, że ​​nie wymaga procesora adnotacji czasu kompilacji, wydaje się, że procesor adnotacji czasu kompilacji wysadza proces kompilacji. Ilekroć jestem w NetBeans i mam adnotacje czasu kompilacji włączone w Kompilacji-> Kompilowanie we właściwościach projektów, otrzymuję mgławicową serię błędów.

Mam zamiar spróbować otworzyć nowy bilet błędu dla problemu i po prostu myślałem, że przejdę na łatwe obejście na teraz.

Answer 6

nadal obecny przy użyciu javac 1.6.0_26. Sposób obejścia problemu przez Yurez przy użyciu w pełni kwalifikowanej nazwy typu podczas określania wartości domyślnej nadal działa.

Answer 7

Działa z pełną nazwą typu.

import java.lang.annotation.ElementType; 
import java.lang.annotation.Retention; 
import java.lang.annotation.RetentionPolicy; 
import java.lang.annotation.Target; 

import com.io.CacheType; 

@Retention(RetentionPolicy.RUNTIME) 
@Target({ElementType.METHOD}) 
public @interface Cacheable { 
public CacheType value() default com.io.Cachetype.COMMON; 
} 

Answer 8

uznał ten problem został rozwiązany w 1.6.0_31 i 1.7.0_03 (być może również w niektórych poprzednich wersjach), więc po prostu uaktualnić kompilator Javy.