explizite initialisierung mit null

phudy

auszug aus der checkstyle option "Explicit Initialization":

"Checks if any class or object member explicitly initialized to default for its type value (null for object references, zero for numeric types and char and false for booolean.

Rationale: each instance variable gets initialized twice, to the same value. Java initializes each instance variable to its default value (0 or null) before performing any initialization specified in the code. So in this case, x gets initialized to 0 twice, and bar gets initialized to null twice. So there is a minor inefficiency. This style of coding is a hold-over from C/C++ style coding, and it shows that the developer isn't really confident that Java really initializes instance variables to default values."

demnach macht es einen mehraufwand, wenn man objekte mit null (zahlen mit 0) explizit initialisiert. aber ist nicht der compiler schlau genug das zu optimieren???
wer kennt da die interna vom javac genau?

Plantschkuh!

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:

Code

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

Wenn ich das so kompiliere, wird folgender Code generiert:

Code

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:

Code

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
}

Alles anzeigen

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.

phudy

aeusserst nette herangehensweise um das zu beweisen :thumb: vielen danke

also is der compiler echt so doof und optimiert das nicht weg -idiot.

und bzgl deiner letzten anmerkung wegen dem stil: nun ja, da hast du vollkommen recht. lieber 30ms langsamer als das irgendwann sich ein fehler einschleicht (deshalb pfuschen wir ja auch nimma mit zeiger rum :verycool: ). aber man kann -einen gscheiten compiler vorausgesetzt- eigentlich beides haben...

wie waers mit einem ticket fuer sun microsystems? gibts da sowas wie ne wishlist?

ps: wusste gar net dass der michael jackson programmieren kann
pps: wusste erst recht net, dass der herr jackson einen zweiten vornamen hat

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.

a9bejo

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

a9bejo

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.

Code

static int TIMEOUT = 0;  //seconds

hal

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.

laborg

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?

a9bejo

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.

hal

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.

Jetzt mitmachen!