2011-12-23 12 views
38

In C#, abbiamo 2 modalità per creare progetti: Debug e Release, mi chiedo se Java abbia la stessa cosa. Sto usando IntelliJ IDEA come IDE Java e finora non ho visto da nessuna parte configurare una modalità di compilazione come in VS IDE.Java ha la modalità di build 'Debug' e 'Release' come C#?

+0

hai cercato nel Web qualcosa come ** java usando assert **? Per quanto riguarda IDEA, se guardi all'interno di /bin/idea.exe.vmoptions probabilmente troverai che viene eseguito in modalità 'Debug' stesso - se è presente l'impostazione' -ea' :) – gnat

+0

@gnat, sì, c'è l'impostazione '-ea' in' idea.exe.vmoptions'.Ma che dire di quando costruisce un artefatto (un file jar), ancora in modalità 'Debug' con un artefatto? – JatSing

+1

nel file vmoptions, '-ea' influenza il modo in cui viene eseguito IDEA (è un'applicazione java che conosci?) ** non ** il codice che costruisce. Per quanto riguarda i vasi, gestisci la loro modalità in runtime specificando o omettendo '-ea'. Come ho scritto, basta cercare web per asserire java ci sono molti tutorial su quello – gnat

risposta

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

È possibile scegliere di includere i simboli di debug nelle classi compilate (questo è il valore predefinito) o di non farlo. Non c'è molto vantaggio nel non farlo. I file jar saranno a little smaller, ma il vantaggio prestazionale è minimo (se presente). Senza questi simboli non si ottengono più i numeri di riga nelle tracce dello stack. Hai anche la possibilità di includere additional symbols with local variable names (per impostazione predefinita ci sono solo nomi di file di origine e numeri di riga).

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

È possibile anche abilitare asserzioni in fase di esecuzione (di default è disattivata), che a volte è utile durante lo sviluppo e la sperimentazione. Questo ha un impatto sulle prestazioni (se il codice in questione ha fatto effettivamente uso di asserzioni, che penso sia uncommon).

Indipendentemente da una qualsiasi di queste impostazioni, la JVM consente sempre di allegare un debugger.

Ciò che Java non possiede è una compilazione condizionale in cui un codice completamente diverso verrebbe compilato in base ad alcune impostazioni esterne. Il più vicino che puoi ottenere è qualcosa come public static final boolean DEBUG_BUILD = true; da qualche parte nel tuo codice e usa le istruzioni if. In questo modo il compilatore esclude il codice che diventa irraggiungibile, ma devi impostare questa costante nel codice sorgente.

+1

in ogni caso per rendere 'public booleano finale DEBUG_BUILD' in pre-elaborazione, qualcosa come' # ifdebug' in C#? – JatSing

+3

@JatSing: non direttamente. Potresti avere una sorta di script che aggiorna il valore prima di avviare il compilatore. O magari avere un Constants.java e due versioni di questo, e impostare il classpath di compilazione per uno di essi. Ma nulla nella toolchain ufficiale. – Thilo

4

Stai chiedendo diversi tipi di build da compilare in cose diverse, immagino. Ad esempio, per avere Debug.WriteLine e Console.WriteLine.

"No, Java non ha una corrispondenza esatta per tale funzionalità. È possibile utilizzare gli aspetti o utilizzare un contenitore IOC per iniettare classi di implementazione diverse." ha rubato questo dal seguente domanda: Conditional Java compilation

(ci sei altre risposte belle per voi lì)

13

È prassi normale in Java per rilasciare tutto è un modo che può essere il debug. Per alcuni progetti che richiedono l'offuscamento, potrebbero avere una build di rilascio, ma non l'ho mai visto in 12 anni di sviluppo di Java.

Cose come asserzioni e messaggi di debug in genere sono disattivate in fase di esecuzione per un'istanza di produzione, ma possono essere attivate in qualsiasi momento (anche in modo dinamico) se necessario.

IMHO è consigliabile utilizzare la stessa build in tutti gli ambienti, non solo la stessa fonte ma gli stessi JAR. Questo ti dà la migliore possibilità che, se funziona in prova, funzionerà in produzione e se hai un problema nella produzione, puoi riprodurlo in prova.

Poiché così tanto codice Java è scritto in questo modo, il JIT è molto bravo a ottimizzare il codice morto che non viene mai chiamato. Tanto che IMHO la maggior parte dei micro-"benchmark" in cui Java out esegue C++, è quando il benchmark non fa nulla e il JIT è più bravo a rilevarlo. IMHO, C++ presuppone che lo sviluppatore sia abbastanza intelligente da non scrivere codice che non faccia nulla.

+1

"Non l'ho mai visto in 12 anni di sviluppo di Java". Per me, questa è la parte più rilevante della tua risposta, mentre stai scrivendo Java per HFT (!). Ciò significa che la compilazione del codice Java per includere tutte le informazioni di debug fa/non/interferisce con JIT JVM? Presumo di sì, ma cerco conferma. – kevinarpe

Problemi correlati