2011-12-23 14 views
38

W języku C# mamy 2 tryby budowania projektów: Debug i Release, ciekawe, czy Java ma to samo. Używam IntelliJ IDEA jako Java IDE i do tej pory nie widziałem nigdzie, aby skonfigurować tryb kompilacji, jak w VS IDE.Czy Java ma tryb debugowania i "wydania", jak C#?

+0

wyszukiwałeś w Internecie czegoś podobnego ** java używając assert **? jeśli chodzi o IDEA, jeśli zajrzysz do /bin/idea.exe.vmoptions, najprawdopodobniej okaże się, że działa w trybie 'Debugowanie' - jeśli jest obecne ustawienie' -a' :) – gnat

+0

@gnat, tak, jest Ustawienie "-ea" w pliku 'idea.exe.vmoptions'.Ale co powiesz na to, kiedy buduje artefakt (plik jar), wciąż w trybie "Debugowanie" z artefaktem? – JatSing

+1

w pliku vmoptions, '-ea wpływa na sposób działania IDEA (jest to aplikacja Java, którą znasz?) ** nie ** kod, który buduje. Jeśli chodzi o słoiki, zarządzasz ich trybem w środowisku wykonawczym, podając lub pomijając "-ea". Jak napisałem, po prostu wyszukaj w sieci dla java twierdzenie, że istnieje wiele tutoriali na temat tego – gnat

Odpowiedz

32
javac 
    -g       Generate all debugging info 
    -g:none     Generate no debugging info 
    -g:{lines,vars,source}  Generate only some debugging info 

Możesz włączyć symbole debugowania w skompilowanych klasach (jest to ustawienie domyślne) lub tego nie robić. Nie ma wiele korzyści, aby tego nie robić. Pliki jar będą miały wartość a little smaller, ale korzyści związane z wydajnością są minimalne (jeśli występują). Bez tych symboli nie będzie już numerów linii w śladach stosu. Istnieje również opcja włączenia additional symbols with local variable names (domyślnie są tylko nazwy plików źródłowych i numery linii).

java 
    -ea[:<packagename>...|:<classname>] 
    -enableassertions[:<packagename>...|:<classname>] 
        enable assertions 

Można również włączyć asercje w czasie wykonywania (domyślnie jest wyłączona), co jest czasem przydatne podczas programowania i testowania. Ma to wpływ na wydajność (jeśli dany kod rzeczywiście korzystał z asercji, które moim zdaniem są uncommon).

Niezależnie od tych ustawień JVM zawsze umożliwia dołączenie debuggera.

To, czego nie ma Java, to kompilacja warunkowa, w której skompilowany zostałby zupełnie inny kod na podstawie niektórych ustawień zewnętrznych. Najbliższe, co możesz uzyskać, to coś takiego, jak public static final boolean DEBUG_BUILD = true; gdzieś w kodzie i użyj tego w instrukcjach if. Dzięki temu kompilator wykluczy kod, który stanie się nieosiągalny, ale musisz ustawić tę stałą w kodzie źródłowym.

+1

tak czy inaczej, aby 'public static final boolean DEBUG_BUILD' na preproces, coś jak' # ifdebug' w C#? – JatSing

+3

@JatSing: Nie bezpośrednio. Możesz mieć jakiś skrypt, który aktualizuje wartość przed uruchomieniem kompilatora. A może masz Constants.java i dwie wersje tego i ustawiasz ścieżkę klas kompilacji dla jednego z nich. Ale nic w oficjalnym toolchain. – Thilo

4

Pytasz o różne rodzaje kompilacji do kompilacji w różnych rzeczach, jak sądzę. Na przykład, aby mieć Debug.WriteLine i Console.WriteLine.

"Nie, Java nie ma ścisłego dopasowania do tej funkcji. Można użyć aspektów lub użyć kontenera IOC do wstrzyknięcia różnych klas implementacji." ukradł to z następującym pytaniem: Conditional Java compilation

(są tam inne miłe odpowiedzi na ciebie tam)

13

Jest to normalna praktyka w Javie, aby zwolnić wszystko jest sposób, który może być pozbawione błędów. W przypadku niektórych projektów, które wymagają zaciemniania, mogą one zawierać kompilację wydania, ale nigdy nie widziałem tego od 12 lat programowania Java.

Rzeczy takie jak asercje i komunikaty debugowania są zwykle wyłączane w środowisku wykonawczym dla instancji produkcyjnej, ale można je włączyć w dowolnym momencie (nawet dynamicznie), jeśli jest to wymagane.

IMHO Najlepszą praktyką jest używanie tej samej wersji w każdym środowisku, a nie tylko w tym samym źródle, ale w tych samych JAR-ach. Daje to największą szansę, że jeśli zadziała w teście, zadziała w produkcji i jeśli masz problem z produkcją, możesz go ponownie wyprodukować w teście.

Ponieważ tak wiele kodu Java jest napisane w ten sposób, JIT jest bardzo dobry w optymalizacji martwego kodu, który nigdy nie jest wywoływany. Tak bardzo, że IMHO większości mikro- "benchmarków", w których Java out wykonuje C++, jest wtedy, gdy benchmark nic nie robi, a JIT lepiej to wykrywa. IMHO, C++ zakłada, że ​​programista jest wystarczająco inteligentny, aby nie pisać kodu, który nic nie robi.

+1

"Nigdy nie widziałem tego od 12 lat prac nad Javą". Dla mnie jest to najważniejsza część twojej odpowiedzi, gdy piszesz Javę dla HFT (!). Czy to oznacza, że ​​kompilowanie kodu Java w celu uwzględnienia wszystkich informacji dotyczących debugowania powoduje/nie wpływa na JIT JVM? Zakładam, że tak, ale proszę o potwierdzenie. – kevinarpe

Powiązane problemy