2011-01-15 21 views
9

Widziałem niektóre kody w slf4j, jak pokazano poniżej. Nie wiem, dlaczego unikać ciągłego składania tutaj. Czy to konieczne? lub po prostu najlepsza praktyka. jaka jest korzyść z robienia tego?dlaczego unikać ciągłego składania w Javie? Gdy?

Dzięki.

/** 
    * Declare the version of the SLF4J API this implementation is compiled against. 
    * The value of this field is usually modified with each release. 
    */ 
// to avoid constant folding by the compiler, this field must *not* be final 
public static String REQUESTED_API_VERSION = "1.6"; // !final** 
+0

Przeglądałeś wiki na ten temat? Myślę, że wyjaśnia to całkiem dobrze. http://en.wikipedia.org/wiki/Constant_folding – CoolBeans

+0

Możesz użyć metody zamiast eksponować to pole (prawdopodobnie najlepiej), użyj 'final', ale podaj wartość za pomocą metody (' "1.6" .toString() ') lub dodaj jakiś kod, aby nie był on * stałą czasu kompilacji *, ale nie dodaje niepotrzebnego kodu bajtowego ('null! = null?" ":" 1.6 "'). –

+0

Tak, publiczne statyczne stałe są icky! –

Odpowiedz

6

W szczególnym przypadku, gdy jesteś puszczania bibliotekę, często nie mają kontroli nad ostateczną wersją biblioteki logowania, który jest powiązany w końcu na końcu. Na przykład używasz wersji 1.6, a aplikacja korzystająca z Twojej biblioteki może użyć wersji 1.6.1, aby uzyskać poprawkę. Ponieważ jest to tylko punktowa wersja, API powinno być kompatybilne, ale jeśli twoja biblioteka sprawdza wersję SLF4J, powinna pokazywać 1.6.1, a nie 1.6.

Jeśli stała jest zakreślona, ​​zobaczysz 1.6 (ponieważ jest ona skopiowana do pliku klasy), nawet jeśli biblioteka została uaktualniona po fakcie.

+0

Projekt, nad którym pracowałem, AviSynth, odkrył to na własnej skórze, kiedy postanowił rozszerzyć swoją ABI pomiędzy mniejszymi wersjami. Nie było to możliwe ze względu na zbyt dużą zależność i zbyt dużą zależność od VC6. Następna ważna wersja wykorzystała "wirtualny" ABI i działała świetnie. – SilverbackNet

Powiązane problemy