Statyczne klasy wewnętrzne wymagają importu dla adnotacji.

Question

Przeprowadziłem więc test jUnit i chciałem napisać odrębne klasy, które miały podobną funkcjonalność, ale były wystarczająco małe, aby pisać w ramach jednej klasy. Niezależnie od decyzji dotyczącej projektu spowodowało to błąd kompilatora. Nie jestem pewien, jakie są reguły dotyczące tego, co widziałem.

Można sobie wyobrazić, że to wyglądać

package foo; 

@RunWith(Suite.class) 
@SuiteClasses({ TestClassOne.class, TestClassTwo.class }) 
public class TestSuite{ 

    @RunWith(SpringJUnit4ClassRunner.class) 
    public static class TestClassOne{ 

    } 

    @RunWith(SpringJUnit4ClassRunner.class) 
    public static class TestClassTwo{ 

    } 
} 

Teraz gdy kompilator wykopuje go powie TestClassOne nie mogą być rozwiązane do rodzaju. Istnieje prosty sposób rozwiązania tego problemu. Wymagałoby to na przykład wyraźnego importu klasy statycznej.

import foo.TestSuite.TestClassOne; 
import foo.TestSuite.TestClassTwo; 

moje pytanie, może ktoś wytłumaczyć co kompilator przepisy lub powody mogą istnieć na adnotacje, aby nie być w stanie zobaczyć klasę statyczną klasę wewnętrzną. Należy pamiętać, że klasa prywatna pakietu jest dobrze widoczna i kompiluje się bez importowania.

Answer 1

To jest interesujące. Zgodnie z [1], zakres nazwy "TestClassOne" to "cały korpus" klasy "TestSuite".

Czy adnotacja znajduje się w "treści" TestSuite? Najwyraźniej nie. Ale to nie jest sprawiedliwe. Reguła zakresu została zdefiniowana przed wprowadzeniem adnotacji. Nie widzę problemu, jeśli adnotacja klasy jest rozważana w zakresie klasy. Są i tak bardzo intymne.

Kolejne pytanie brzmi: w jaki sposób można odwoływać się do adnotacji do prostej nazwy "TestSuite"? Okazuje się, że specyfikacja dotyczy tego. Adnotacja jest modyfikatorem, który jest częścią deklaracji typu, a "Zakres typu najwyższego poziomu to wszystkie deklaracje typu w pakiecie".

Możliwe jest jednak, że specyfikacja trafiła do niego przypadkowo. Reguły zostały zdefiniowane przed wprowadzeniem adnotacji i pozostały takie same później. Tak więc, chociaż dotyczy to przypadku technicznego, może to być wypadek. Nie jest to wątpliwe w siłę mózgu projektantów języków - cała specyfikacja jest zbyt cholernie złożona.

[1] http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3

Answer 2

Nie trzeba importować wewnętrzną klasę, można uzyskać do nich dostęp za pomocą

TestSuite.TestClassOne 

szczegóły mogą być znalezione w JLS, ale moja prosta zasada: AN import a.b.c.d.e pozwala używać zamiast e w pełni kwalifikowanej nazwy. To nie pozwala na użycie f.

Answer 3

Wystarczy dodatkowa informacja: jest to niezbędne do importowania klas nie tylko wewnętrzne przy użyciu adnotacji, ale również podczas używania go jako parametrycznej typu, co jest bardzo irytujące.