2012-10-08 20 views
5

Kiedy kompiluję i uruchamiam mój projekt w Eclipse z JDK7 lub JDK6, wszystko jest w porządku. Jednak po tym, jak budować go za pomocą ANT a następnie próbował go uruchomić za pomocą systemu JDK7, pojawia się błąd:Java 7 - Niespójne ramki klatek stosu - Potrzebujesz pomocy w zrozumieniu, dlaczego działa rozwiązanie

niespójne ramek stackmap w wybrany oddział 25 w metodzie myClass.myMethod() [[Ljava/lang/przedmiot; w offsecie 14

szukałem wszędzie i znalazłem parę dobrych pytania tutaj na StackOverflow:

Zarówno zasadniczo sugerowałyby, aby dodać -XX:-UseSplitVerifier jako Opcja JVM, która rozwiązała problem. Nadal nie w pełni rozumiem, dlaczego, ale najwyraźniej this bug report ma pomóc. Niestety nadal go nie dostaję ...

Zauważyłem na jednym z pytań, że ktoś używa programowania zorientowanego na aspekt, co sprawiło, że myślę, że używam Guice (struktura Google DI), które może spowodować problem ale nie widzę jak. Ma obsługiwać JDK7.

Używam również Proguard, ale to też ma działać z JDK7.

W każdym razie nie mam pojęcia, dlaczego to obejście działa inaczej niż w zasadzie wraca do poprzedniej wersji JDK (w tym przypadku JDK6), gdy jakaś część kodu próbuje grać z kodem bajtu (który dlaczego myślę, że jest to związane z DI). Ale nadal nie jestem w stanie stworzyć odpowiedniego linku. I mogę też być daleko!

Jeśli ktoś mógłby wyjaśnić, co się dzieje i dlaczego tak się dzieje, byłbym bardzo wdzięczny. Naprawdę nienawidzę konieczności stosowania obejścia, ponieważ nie jest to rozwiązanie, które uważam za długoterminowe.

+0

* "To ma obsługiwać JDK7." * - może jego obsługa jest błędna. Czy przeszukujesz tracker/grupy zagadnień Guice? –

+0

Nie udało mi się znaleźć niczego w kwestii błędów w ich trackerze problemów –

+0

Zgaduję, że w java7 dodali bardziej agresywny kod bajtowy weryfikujący kontrole i cokolwiek robi z kodem bajtowym, aby wykonać wtrysk zależności nie działa z tymi sprawdzeniami –

Odpowiedz

3

Od wersji 7 Java skompilowany kod bajtowy musi zawierać dodatkowe atrybuty StackMapTable. Pomagają one weryfikatorowi wewnątrz maszyny JVM sprawdzać, czy klasy są solidnie zbudowane w czasie ładowania klasy. Wcześniejsze wersje Javy są łagodniejsze, co oznacza wolniejszą weryfikację bez atrybutów.

Narzędzia modyfikujące oryginalny skompilowany kod bajtowy (ProGuard zaraz po kompilacji, ramy AOP tuż przed wykonaniem ...) muszą zaktualizować atrybuty zgodnie ze zmodyfikowanym kodem. Jeśli tego nie zrobią, pojawi się komunikat o błędzie "Niespójne ramki stosu".

ProGuard powinien wykonać tę karę z tytułu wstępnej weryfikacji; Nie mam żadnych problemów z tym. Jeśli nadal widzisz błąd bez stosowania ProGuard, problem musi być związany z DI lub AOP.