warum in *.class-Dateien loggen?

[Guest]

Hallo,

:### in einen Buch hab ich folgendes gelesen:

:meld: Im Entwickler-Build sollen jedoch expliziet alle verfügbaren Debug-Informationen in die .class Dateien eingebunden werden.

Hierzu eine Frage:

Warum werden in die .class Dateien Debug-Informationen eingebunden? Man loggt doch nicht in die .class Dateien rein... hab ich bisher zumindest nie so gemacht. Eigentlich sollten die Debug Informationen doch in die Console und zusätzlich in eine log-Datei.

Könnt ihr mir kurz erklären, was mit diesem Satz gemeint ist?

 

[SlaterB]

http://narencoolgeek.blogspot.com/2005/12/debug-information-in-java-class-files.html

 

[Guest]

mmm... habs mir mal durchgelesen. Mein Englisch ist leider nicht das beste. Was ich mitgenommen habe ist, dass man wirklich bewußt in die *.class Dateien loggt. Was ich allerdings noch nicht verstanden habe:

Warum loggt man in die Class-Dateien, wenn man es doch auch in eine Log-Datei loggen kann? In der Log-Datei wäre der ganze Kram doch viel übersichtlicher?

 

[SlaterB]

es geht darum dass beim Compilieren mehr Informationen aus dem Quellcode mit in die .class-Datei übernommen wird,
z.B. Namen von lokalen Variablen,

ein Logger kann damit vielleicht nicht mehr anfangen als vorher, aber höhere Debugging-Tools finden sowas gut

http://de.wikipedia.org/wiki/Debugger

 

[Ebenius]

Warum loggt man in die Class-Dateien, wenn man es doch auch in eine Log-Datei loggen kann? In der Log-Datei wäre der ganze Kram doch viel übersichtlicher?

Da hast Du was ganz falsch verstanden. Der Compiler fügt Debug-Informationen in die .class-Dateien ein. Diese Informationen enthalten zum Beispiel Zeileninformationen bezogen auf den Java-Quelltext. Das ist zum Beispiel wichtig, damit man weiß, an welcher Stelle im Quelltext ein Fehler aufgetreten ist.

Das ganze ist einstellbar, siehe javac command line syntax:

$ javac -help

Usage: javac <options> <source files>
where possible options include:
  -g                         Generate all debugging info
  -g:none                    Generate no debugging info
  -g:{lines,vars,source}     Generate only some debugging info

Hilft das?

Grüße, Ebenius

 

[Guest]

Kann ich mir das so vorstellen:

Szenario 1:

Person A kompiliert den Quellcode so, dass KEINE Debuginformationen in die *.class Dateien geschrieben werden. Anschließend startet sie das Programm. Das Programm stürzt bei Methode test ab, da diese Methode einen Fehler enthält. Nun kann mir die JVM zwar anzeigen welcher Fehler aufgetreten ist, sie kann mir allerdings nicht sagen, in welcher Zeile des Quellcodes (*.java), da die Classdateien ja keine Debuginformationen enthalten und damit auch keine Zeileninformationen.

Szenario 2:

Person B kompiliert den Quellcode so, dass Debuginformationen in die *.class Dateien geschrieben werden. Anschließend startet sie das Programm. Das Programm stürzt bei Methode test ab, da diese Methode einen Fehler enthält. Nun kann mir die JVM anzeigen welcher Fehler aufgetreten ist. Außerdem kann sie anzeigen, in welcher Zeile des Quellcodes (*.java), da die Classdateien ja nun Debuginformationen enthalten und damit auch Zeileninformationen.

 

[Ebenius]

Kann ich mir das so vorstellen: [...]

Das ist ziemlich richtig, ja.

Im Beispiel sieht das dann so aus:

package com.ebenius;

public class A {
  public static void main(String[] args) {
    throw new NullPointerException("Nope");
  }
}

Mit Debug-Info "line" & "source" siehst Du:

Exception in thread "main" java.lang.NullPointerException: Nope
at com.ebenius.A.main(A.java:5)

Ohne Debug-Info "line", aber mit Debug-Info "source" siehst Du:

Exception in thread "main" java.lang.NullPointerException: Nope
at com.ebenius.A.main(A.java)

Ohne Debug-Info "line", "source" siehst Du:

Exception in thread "main" java.lang.NullPointerException: Nope
at com.ebenius.A.main(Unknown Source)

EDIT: Damn it, ich bin heut zu blöd für BB-Code :-D

Grüße, Ebenius

 

[Guest]

Dann noch schnell zwei abschließende Fragen:

1.)
Das ich die Debug-Informationen beim Entwickler-Build brauche ist klar. In dem Buch wird allerdings geschrieben, dass man die Debug-Informationen beim Integration-Build und beim Release-Build weglassen sollte. Wieso eigentlich? Sind die Debug Informationen innerhalb der *.class so Performancelastig?

2.)
In der default-Einstellung von javac werden die Debug-Informationen geschrieben oder? Ich könnte jetzt auch nachschauen... aber vielleicht kannst du mir es ja direkt sagen?

 

[Landei]

1.) Ich denke, dass das nur einen minimalen Unterschied macht. Du solltest die debug-Informationen drin lassen, falls du nicht auf das allerletzte Quentchen Performance angewiesen bist.

 

[tfa]

Debuginformationen kann man aus den Class-Dateien nehmen, wenn man sich sicher ist, dass das Programm perfekt ist und nie wieder Fehler auftreten. Also niemals.
Die Performanceeinbußen sind sicherlich nicht messbar.
Was ist denn das für ein Buch?

 

[SlaterB]

sind Debug-Informationen auch ein Sicherheitsproblem, Stichwort Dekompilierung? 😉

 

[Ebenius]

sind Debug-Informationen auch ein Sicherheitsproblem, Stichwort Dekompilierung? 😉

Sicher. Wenn Du Dir darüber Sorgen machst, dann kannst Du die "var"-Infos rauslassen. Also:

javac -g:source -g:line

Allerdings bringt das auch nur wenig Sicherheit. Ein Obfuscater wäre da angebracht. Aber meiner Meinung nach machen sich die Leute die sowas tun a) mehr Aufwand als gut ist und b) mehr Probleme als Freude.

Grüße, Ebenius

 

[Ebenius]

1.) [...] Sind die Debug Informationen innerhalb der *.class so Performancelastig?

Ein bisschen größer und fast nicht langsamer. Wir lassen sie immer drin und ich empfehle jedem (der das darf) es genauso zu tun.

2.) In der default-Einstellung von javac werden die Debug-Informationen geschrieben oder? [...]

Ja, Sun scheint meine Meinung zu teilen. 😀

Grüße, Ebenius

 

[Guest]

Was ist denn das für ein Buch?

Konfigurationsmanagement mit Subversion, Ant und Maven. Ein echt geiles Buch!!!