Le opzioni di compilazione predefinite non includono le informazioni di debug, è necessario specificare specificamente al compilatore di includerlo. Ci sono diversi motivi per cui la maggior parte della gente lo omette:
- Alcune librerie sono utilizzate in sistemi embedded (come i telefoni cellulari). Fino a poco tempo fa, ogni piccolo conto. Oggi la maggior parte dei cellulari ha più memoria di tutti i computer nel 1985 insieme;)
- Quando compilato con il debug attivo, il codice viene eseguito più lentamente del 5%. Non molto ma ancora, in alcuni casi ogni ciclo conta.
- I Senior Developer di oggi sono nati in un'epoca in cui 64 KB di RAM erano enormi. Ieri ho aggiunto un'altra unità da 2 TB al mio server in cantina. Sono 7 ordini di grandezza in 25 anni. Gli umani hanno bisogno di più tempo per adattarsi.
[EDIT] Come sottolineato da John, il bytecode Java non è più ottimizzato (molto) oggi. Quindi l'output dei file di classe sarà lo stesso per entrambi i casi (solo il file di classe con le informazioni di debug sarà più grande). Il codice è ottimizzato in JIT in runtime che consente al runtime di ottimizzare il codice per CPU, memoria (quantità e layout), ecc.
La penalità del 5% menzionata è quando si esegue il codice e si aggiunge la riga di comando opzioni per consentire a un debugger remoto di collegarsi al processo. Se non abiliti il debug remoto, non c'è penalità (tranne che per il caricamento di classe, ma ciò accade solo una volta).
fonte
2009-12-09 09:00:37
Molto spesso, si dovrebbe essere in grado di scaricare una versione non ottimizzata/"debuggable" della lib, o si può semplicemente mordere il proiettile e tirare giù lo src da soli – Ian