Es gibt einen englischsprachigen Artikel in dem einige interessante Kritikpunkte zu Java stehen:
Einen davon finde ich wirklich interessant: Java hat keine "struct"s die man aus C kennt. Mit dem struct Schlüsselwort kann man mehrere Typen zusammenfassen. Die sind ähnlich wie Klassen, können aber auch auf dem Stack erzeugt werden (ganz ohne Heap).
Z.B. könnte man sowas schreiben:
//gewöhnlicher java code:
public static void foo(){
int x=0;
int y=1;
bar(x, y);
}
public static void bar(int x, int y){}
//wäre mit structs äquivaltent zu:
struct Point{
int x;
int y;
}
public static void foo(){
//hier ist "new" nicht erforderlich. Die variablen x und y werden als lokale variablen deklariert.
Point p;
p.x=0;
p.y=1;
bar(p);
}
public static void bar(Point p){}
bei diesem Beispiel ist ein struct reiner „syntaktischer Zucker“, der Kompiler kümmert sich um die deklaration der lokalen Variablen. Der Kompiler müsste sich auch um die übergabe solcher Strukts als Parameter kümmern in dem er für diesen die richitige Anzahl an Parametern synthetisiert.
Interessanter wäre aber die Deklaration von struct-Arrays:
//Gewöhnlicher java code:
Object[] arr=new Object[4];
arr[0]="key1";
arr[1]=42;
arr[2]="key2";
arr[3]=43;
//hier ist ein cast notwendig:
Integer value=(Integer)arr[1];
//struct äquivalent:
struct Entry{
String key;
Integer value;
}
//der kompiler erzeugt hier ein array ungefähr so: new Object[2 * sizeof(Entry)];
Entry[] arr=new Entry[2];
//"new Entry" ist nicht erforderlich
arr[0].key="key1";
arr[0].value=42;
arr[1].key="key2";
arr[1].value=43;
//und hier wird es spannend, da der Kompiler genau weiss welche typen der struct definiert ist hier kein cast erforderlich:
Integer value=arr[0].value;
Ich bin mir nicht sicher ob die JVM selbst einen cast vorschreibt bei dem obigen Besipiel, aber es wäre interessant den ByteCode zu generieren ohne den Cast, also an den Stellen wo man sicher ist welche Typen man im Array hat. Somit könnte man eine HashMap implementieren die nicht mehr die Klasse Entry braucht. So eine HashMap Implementation wäre sicherlich viel schneller als die aus dem JDK.
wir, dass das so bleibt…
Die genaue Abgrenzung wird vielleicht nach dem Lesen des Links klarer, aber es gibt offensichtlich einen großen Overlap, wie der zitierte Abschnitt auch sagt.
Aber… man braucht es wirklich selten.