explizite initialisierung mit null

Ich kenn die Interna vom javac zwar nicht, aber ich weiß, daß man sich mit javap -c den generierten Bytecode von einer Klasse ansehen kann. Also auf gehts:

class InitTest
{
    boolean flag;
    InitTest a, b, c;
}

Wenn ich das so kompiliere, wird folgender Code generiert:

InitTest();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return
}

Wenn ich jedoch flag händisch auf false und die Referenzen auf null setze:

InitTest();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   aload_0
   5:   iconst_0
   6:   putfield        #2; //Field flag:Z
   9:   aload_0
   10:  aconst_null
   11:  putfield        #3; //Field a:LInitTest;
   14:  aload_0
   15:  aconst_null
   16:  putfield        #4; //Field b:LInitTest;
   19:  aload_0
   20:  aconst_null
   21:  putfield        #5; //Field c:LInitTest;
   24:  return
}

Das schaut nicht nur länger aus; wenn ich in einem dilettantisch ausgemessenen Testprogramm 4 Milliarden Objekte dieser Klasse erzeuge, kriege ich recht konsistent 10-20 Sekunden Unterschied in der Laufzeit (bei 6-7 Minuten für einen Durchlauf). D.h. wenn jede Initialisierung (boolean und Referenz) gleich lang dauert, haben wir ca. 16 Sekunden / 16 Milliarden Initialisierungen = größenordnungsmäßig eine Nanosekunde pro Initialisierung, wenns stimmt. Das real-world-Programm, wo man das merkt, muß man mir mal zeigen...

D.h. ja, die Optimierung wäre watscheneinfach, wird aber zumindest von meinem javac so, wie ich ihn verwende, nicht durchgeführt.

Ich finde den Ratschlag trotzdem fragwürdig, die zwei Regeln der Optimierung gehen meiner Meinung nach eindeutig vor:

Zitat von M.A. Jackson

Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.

Allerdings gehts nicht nur um Optimierung, sondern auch um Stil, und da gibts wie überall auch zwei Denkschulen: Die eine meint, der Code ist für den nächsten Leser klarer, wenn explizit initialisiert wird, weil man dann nicht lang darüber nachdenken muß, ob und wie die Variablen jetzt initialisiert werden -- die andere sagt, alles unnötige lenkt nur ab, und wer über sowas nachdenken muß und nicht sofort weiß, was die Defaultwerte sind, sollte keine Javaprogramme warten.

Nachdem Java sowieso schreit, wenn man eine Variable uninitialisiert verwendet, glaub ich dass das auf null initialisieren nicht wirklich sinnvoll ist, wenn es nicht notwendig ist.

Interressant.

Ich habe mal auf comp.lang.java.programmer nach dem Thema
gesucht und das hier gefunden:

Zitat

Actually, earlier compilers did NOT generate the
assignment, because the compiler noticed that the
initial value was the same as the default value.

That was considered a compiler defect and it was
fixed. The problem was discovered when trying to
set a breakpoint on the statement, which never
triggered, because no code had been generated
for the statement. Explicit assignments are now
always generated, regardless of the value.

Also, JIT'd code is supposedly debuggable now, so
an explicit assignment of a default value should
not get optimized away by the JIT.

Alles anzeigen

quelle

Zitat von hal

Nachdem Java sowieso schreit, wenn man eine Variable uninitialisiert verwendet, glaub ich dass das auf null initialisieren nicht wirklich sinnvoll ist, wenn es nicht notwendig ist.

Das trifft auf lokale Variablen zu. Instanzvariablen werden aber eben immer initialisiert. Die Frage, ob es verstaendlicher ist wenn man die Zuweisung extra angibt, ist da schon berechtigt.

Ich initialisiere z.B. schon mal gerne explizit, wenn der Wert zwar dem default entspricht, aber eher zufaellig. D.h es gibt auch andere Werte, die hier logisch als default verwendet werden koennten.

z.B.

static int TIMEOUT = 0;  //seconds

Zitat von a9bejo

Interressant.

Ich habe mal auf comp.lang.java.programmer nach dem Thema
gesucht und das hier gefunden[...]

Genau aus dem Grund gibts bei C-compilern Optimierungsswitches. Entweder man wills debuggen oder man wills flott haben, beides geht nicht.

Übrigens ist der java debugger ein Witz, der ist komplett unbrauchbar, und wird offiziell auch nur als "proof of concept" verkauft.

Zitat von hal

Übrigens ist der java debugger ein Witz, der ist komplett unbrauchbar, und wird offiziell auch nur als "proof of concept" verkauft.

Kannst du das, bitte, ein bisschen ausführlicher erklären?

http://www.sucks-rocks.com/rate/jdb/gdb :lol: :engel: :lol:

Ernsthaft: Mich wuerd auch interressieren was an dem java debugger nicht stimmt. Hab schon oefter gehoert das der nicht so heiss sein soll. Ich kann das aber ueberhaupt nicht beurteilen, weil ich selbst keine debugger verwende.

Ich weiß leider nicht mehr genau, wo die Probleme lagen (das war letzten August wie ich den ausprobiert hab), aber irgendwie hats mit den breakpoints nicht wirklich hingehauen, man konnte die lokalen Variablen nicht so gut einsehen, und generell hat der sehr viel Mist ausgegeben, der mir überhaupt nichts gesagt hat. Da liegen Welten zum gdb, der definitiv mein Lieblingsdebugger ist.