Wann wird Eclipse Java 1.5 unterstüzen?

[Gast]

Naja, dann wart ich mal, bis das alles offiziell ist, obwohl ja die Beta schon recht stabil laufen soll.
Kann's jedenfalls kaum erwarten.

Nur von den Generics bin ich enttäuscht. new T()? Geht leider nicht.
Die hätten sich schon ein bisschen mehr vornehmen können, als alles wie bisher zu übernehmen, nur dass der Compiler und nicht der Programmierer die typecasts vornimmt.

[Gregor]

Optimizer schrieb:

new T()? Geht leider nicht.

Dann mußt du an der Stelle wohl mit Reflection arbeiten. Ist doch auch nicht so schlimm, oder?

[Gregor]

Man könnte sich z.B. eine Methode in folgender Art basteln:

public class CreateInstanceTest
{
   public CreateInstanceTest ()
   {
   }

   public static void main (String [] args)
   {
      CreateInstanceTest test = createInstance(CreateInstanceTest.class);
   }

   public static <Type> Type createInstance (Class<Type> typeClass)
   {
      try
      {
         return typeClass.newInstance();
      }
      catch (IllegalAccessException e)
      {
      }
      catch (InstantiationException e)
      {
      }
      return null;
   }
}

[Gast]

Naja, find ich jetzt nicht so unglaublich "weich".
Mich stört ein bisschen die Technik dahinter. Bei den Containern z.B. ändert sich nichts, die verwalten immer noch Objects, nur dass halt der Compiler die ganzen Casts einfügt und man selber sich nicht mehr darum kümmern muss.
Klar, jetzt ist es auf jeden Fall sicher und bequemer, aber trotzdem stört mich diese Vorgehensweise bei den Generics etwas. Vor allem, wenn der cast da intern immer noch drinsteht, muss die VM also praktisch jedesmal nen Typcheck machen. Und primitive Typen werden jedesmal geboxt.

Naja, bringt nichts, da rum zum jammern, ich finds halt ein bisschen schade...

[Gregor]

Ok, ich finde es auch nicht gerade optimal gelöst. Solche suboptimalen Implementierungen sind wohl der Preis, wenn man halbwegs kompatibel bleiben möchte.

Das "new T()" nicht geht, halte ich persönlich aber nicht für wichtig. Es wäre auch mit dem restlichen Java nicht kompatibel, weil man nirgendwo angeben kann, dass eine Klasse einen parameterlosen Konstruktor anbieten muss.

PS: Man kann natürlich mehr machen als nur rumjammern. Zum Beispiel könnte man für RFE 4487555 stimmen.

[Gast]

weil man nirgendwo angeben kann, dass eine Klasse einen parameterlosen Konstruktor anbieten muss.

naja ich dachte da eher an ein System wie bei den C++ Templates. Das Ding wird compiliert, und wenn man das dann mit einem bestimmten Typ instanziert (zur Compilierzeit!), wird halt ggf. gemeckert. Würde ich auf jeden Fall in vielerlei Hinsicht besser finden.

Was ist das RFE 4487555 genau? Ich hab dazu nur einen Google-Treffer.

[Gregor]

Optimizer schrieb:

naja ich dachte da eher an ein System wie bei den C++ Templates. Das Ding wird compiliert, und wenn man das dann mit einem bestimmten Typ instanziert (zur Compilierzeit!), wird halt ggf. gemeckert. Würde ich auf jeden Fall in vielerlei Hinsicht besser finden.

Fände ich absolut scheiße. Java ist eben kein C++ und so ein Vorgehen würde mit dem Rest von Java überhaupt nicht harmonieren.

[Gregor]

Optimizer schrieb:

Was ist das RFE 4487555 genau? Ich hab dazu nur einen Google-Treffer.

In dem Google-Treffer steht doch schon der Link:

http://developer.java.sun.com/developer/bugParade/bugs/4487555.html

[Gast]

*lol* was hattest du für einen Google-Treffer??

Inwiefern würde das mit dem Rest von Java nicht harmonieren? Ich rede nicht davon, die getrennte Übersetzung aufzugeben. Meine Idee wäre, die generische Klasse als Schablone zu compilieren und wenn man sie dann irgendwann mal benutzt, soll der Compiler die Schablone dann als Muster für die Instanzierung nehmen und daraus eine eigene Klasse erstellen, z.B. Vector<String>.class.
Die Abhängigkeit beim Compilieren wäre auch nicht größer, als wenn eine Klasse die andere braucht. Wenn ich die Klasse xyz nutze, muss sie halt vorhanden sein und das wäre hier das selbe.
Aber so wie es jetzt steht, wird die generische Klasse direkt benutzt und überall typecasts und boxing hingesetzt. Find ich nicht so weich.

Ok, aber immerhin muss man den Generics zugute halten, dass man den Parameter-Typ einschränken kann mit extends und implements.

[Gregor]

Optimizer schrieb:

Meine Idee wäre, die generische Klasse als Schablone zu compilieren und wenn man sie dann irgendwann mal benutzt, soll der Compiler die Schablone dann als Muster für die Instanzierung nehmen und daraus eine eigene Klasse erstellen, z.B. Vector<String>.class.

Ok, wenn eine Klasse von mir 10 verschiedene Vectoren nutzt, dann sollen also 10 zusätzliche Class-Dateien erzeugt werden, die entsprechend zur Laufzeit alle geladen werden müssen? Das kann ja wohl wirklich nicht die Lösung sein.

Meine Idee wäre, nur die Schablonen abzuspeichern und die entsprechenden konkreten Klassen erst zur Laufzeit von der JVM erzeugen zu lassen.

[CengizS]

So wie ich die Generics verstanden habe wird doch gerade das gemacht? Generics werden ähnlich wie bei C oder C++ von einer Art Präprozessor als solche erkannt und als Template wird dann eine Klasse textuell generiert (im Speicher) und diese dann kompiliert so dass das spätere Kompilat beispielsweise bei einer ArrayList genau x Varianten hat - nämlich die x Varianten, die in meinem Code verwendet wurden. Sehe ich das falsch?

[Gregor]

CengizS schrieb:

Sehe ich das falsch?

Ja. Auf der Ebene von Class-Dateien entsprechen generische Java-Klassen AFAIK einfachen Klassen. Da, wo Typparameter vorhanden sind, wird einfach der Typ Object verwendet oder ein anderer Typ, wenn man bei den Typparametern Einschränkungen angegeben hat. Generics existieren bei Java also nur auf Ebene des Javacodes. Auf Bytecode-Ebene sind sie nicht vorhanden.

[Gast]

Wenn du zum Beispiel einen Vector<String> verwendest, hast du in Wirklichkeit einen Vector<Object> und wenn du Vector.elementAt(x).length sagst, macht der Compiler (String)(Vector.elementAt(x)).length draus.

Deshalb sind da lauter sinnlose, ineffiziente typecasts drin, und deshalb geht das natürlich auch nicht mit primitiven Typen. Das einzige was man wirklich gewinnt, ist, dass der Code schöner ist und natürlich sicher ist, so ein Typecast wird niemals fehlschlagen. Aber durchgeführt wird er IMO trotzdem, oder?

[test2]

Optimizer schrieb:

Aber durchgeführt wird er IMO trotzdem, oder?

nein

[Gregor@zuHause]

test2 schrieb:

nein

DOCH!

[test2]

Gregor@zuHause schrieb:

test2 schrieb:

nein

DOCH!

eben net! der wird auto geboxt und das geht ohne cast

[Gregor@zuHause]

test2 schrieb:

Gregor@zuHause schrieb:

test2 schrieb:

nein

DOCH!

eben net!

eben DOCH! :p Das hat garnichts mit Autoboxing zu tun.