Die ganze Wahrheit über JCP

[Guest]

Liest mal das hier durch
The Java Gated Community Process

Wenn man sich das ganze durch den Kopf gehen läßt, dann wundert man sich
nicht mehr, dass die Weiterentwicklung von Java so schleppend voran geht.
Ich kenne eine Firma, die am JCP beteiligt war und nach einem Streit über die
Änderungen in JDK 1.5 ausgestiegen ist. SUN läßt keine konstruktive Kritik zu.
Streitpunkt waren u.a. die Generics, wie sie letztendlich in JDK 1.5 implementiert wurden.

Vorschlag war

Map m = new HashMap(); 
Car a = m.get("Ford"); // Compiler übernimmt den Cast

Die "geniale" Lösung von SUN

Map<String, List<Car>> cars = new HashMap<String, List<Car>>();
Car a = m.get("Ford");

Es ist eine kranke Syntax, es sieht aber so aus, dass man es nicht ändern kann. :roll:

 

[bygones]

keine kranke lösung.... ich als entwickler bin ich der 2. lösung dankbar.

ich weiß genau was sich wie in der map befindet. Ich bin nicht darauf angewiesen, dass andere 100% richtige Kommentare schreiben. Ich sehe somit das ganze nicht als krank sondern als hilfreich an !!

ich halte die erste lösung für unsinnig - sie sagt in keiner weise aus was sich in der map befindet...

ergo: finde deine Aussage falsch

 

[Bleiglanz]

Der Vorschlag ist doch kompletter Unsinn, wo ist da die Typsicherheit? Warum glaubst du dass die geniale Lösung von Sun aus einer Liste von Cars einen Car machen kann? Was soll den der Compiler mit

Map m = new HashMap(); 
m.put("Ford",new Tiitti())
Car a = m.get("Ford")

anfangen? Soll der Compiler "vorwärts" lesen und alles durchschauen - das ist unmöglich!

Auch wenn die Generics in Java sicher nicht optimal sind (Erasure, keine Typinfo zur Laufzeit usw.) - so einfach wie du dir das vorstellst gehts nicht, irgendwas in der Form

Map<String, List<Car>> cars = new HashMap<String, List<Car>>();

muss es geben (sonst kann der Compiler ja nix überprüfen), die Syntax ist natürlich etwas strange (aber auch nicht seltsamer als String s = new String())

 

[Beni]

Ähms, ich hab ein bisschen Mühe mit diesen Quellcodes:
Der 2. enthält einen ziemlich heftigen Fehler, und würde den Compiler nicht überleben.
Und der 1... was passiert denn, wenn ich "Animal a = m.get("Ford");" schreibe? Ich sehe da keine Methoden um zu überprüfen, ob das geht (ausser einer RuntimeException). So auf den ersten Blick sieht das für mich eher nach einem Rückschritt aus (von 0 Typsicherheit auf noch weniger).
Also wie sollte Variante 1 funktionieren?

 

[stev.glasow]

@gast: Wer hat so etwas vorgeschlagen? Konnte in dem Artikel nichts dazu finden.
Wenn es diese von dir angesprochen Firma war würde mich echt mal interssieren was die da als Vorteil sehen? Irgendwie widerspricht das doch einer typensicheren Sprache wie Java oder C.

Und zum Artikel:
Es mag einiges dran sein, und vielleicht würde ich mich auch etwas verarscht vorkommen aber sind solche Partnerschaften nicht sowieso ehr zu Werbezwecken? Man darf sich dann halt als Partner von SUN, Cisco wem auch immer ausgeben. Und ein wirkliches Mitspracherecht kann man doch für 5000$ auch nicht erwarten. Oder war das bei diesem JCP anderes geplant

 

[Guest]

Das ist irgendein Systemhaus in Frankfurt gewesen. Weiß nicht genau.
Ich kam drauf als ich auf diesen Artikel gestossen bin. Es hat mich
an das Gespräch mit dem Kumpel erinnert (ehemaliger Studienkamerad).
Es kann sein, dass ich ihn missverstanden habe und die vorgeschlagene
Variante doch anders ausgesehen hat.
Ich bin der Meinung, dass eine strenge Typenprüfung nur eine Krücke für
den Compiler ist. Es ist durchaus möglich anhand des Codes zu bestimmen,
ob sich Konflikte ergeben oder nicht. Eine Compiler-Warnung, bei falscher
Anwendung, würde ausreichen.
Nehmen wir mal das Beispiel von Bleiglanz

Map m = new HashMap(); 
m.put("Ford",new Tiitti());
Car a = m.get("Ford"); // Warnung vom Compiler und/oder einfach ClassCastException zur Laufzeit

In jedem Fall finde ich sowas besser als

Map m = new HashMap(); 
m.put("Ford",new Tiitti());
Car a = (Car)m.get("Ford"); // ClassCastException

Wenn ich ein Objekt eines unbestimmten Typs einer Variablen vom
bekannten Typ zuweise, dann ist klar, dass ich es casten muss.
Warum nicht gleich auf das Getippe verzichten und die Arbeit dem Compiler
überlassen, unabhängig davon, ob es ClassCastExceptions auslöst oder nicht?

 

[Bleiglanz]

 Map m = new HashMap();
m.put("Ford",new Tiitti());
Car a = m.get("Ford"); // Warnung vom Compiler und/oder einfach ClassCastException zur Laufzeit

lächerlich, ignoriert völlig die Realität von Java, wo eben vieles ausserhalb der Sichtweite des Compilers liegt

 Map m = new HashMap();
 if(strangecondition) m.put(new Tittitit()); else m.put(new Tottli());
 some3rdpartyLibFunction(m);
 Car a = m.get("Ford"); // Warnung vom Compiler und/oder einfach ClassCastException zur Laufzeit

>>und/oder einfach ClassCastException zur Laufzeit

= verzicht auf Generics, toller Vorschlag

 

[dotlens]

es zwingt dich nimand mit Generics zu arbeiten. Das ist deine eigene Entscheidung. Es werden dir aber viel leichter Fehler passieren wenn du ohne Generics arbeitest.
Kannst du mir mal erklären woher der Compiler wissen soll welcher typ ein Objekt zur Laufzeit hat? ;-)

Ein Post reicht *lösch*

 

[Guest]

Mit

Car a = m.get("Ford"); // Warnung vom Compiler und/oder einfach ClassCastException zur Laufzeit

meinte ich nicht, dass es, wie bisher, Fehlermeldungen bringen soll,
sondern eine Warnung, falls Stellen im Code auftauchen, wo Objekte
anderen Typs in eine Collection geschrieben wurden. (egal in welcher Reihenfolge)

Jetzt mal unabhängig von Generics.
Wenn man ein Objekt einer Variable zuweist, die einen bestimmten
Typen hat, dann ist in der alten Syntax ohne Generics immer ein Cast
nötig, sonst ist der Code nicht compilierbar.

Car a = (Car)m.get("Ford");
Car a = m.get("Ford"); // Cast wird bzw. sollte vom Compiler eingefügt werden

Ich finde den Cast einfach nur überflüssig, da er selbstverständlich ist.
Das habe ich mit den Warnungen und ClassCastExceptions gemeint.

Wie auch immer, ich kann mit der neuen Syntax auch leben. Jede Sprache hat ihre
Macken, da muss man durch. Es ist so ähnlich wie das THEN bei Bedingungen in
Pascal (IF Bedingung THEN). Alles nur Krücke für den Compiler. Es steckt keine
Funktionalität dahinter.

 

[Beni]

...Ich finde den Cast einfach nur überflüssig, da er selbstverständlich ist...

Da bin ich ganz anderer Meinung: der Cast ist ein wichtiges Instrument um dem Programmierer zu sagen "Vorsicht, hier könnten Fehler sein". Natürlich könnte das auch der Compiler ausgeben, aber so hat man bereits im Code die Gedankenstütze.

Jede Sprache hat ihre Macken, da muss man durch. ... . Alles nur Krücke für den Compiler. Es steckt keine
Funktionalität dahinter.

Wenn dir das alles nicht passt, kannst du auch Assembler coden. Da hast du auch dieses überflüssige OOP-Quatsch-Zeugs (das eh nur verwirrt) nicht... </sarkasmus>
Sry, ich verstehe deinen Standpunkt überhaupt nicht, Generics sind eine wundervolle Spracherweiterung mit denen die Fehlerwahrscheinlichkeit dramatisch sinkt (und das ist für mich das wichtigste)

 

[stev.glasow]

Der vorschlag hat auch gar nix mit Generics zu tun, im Gegenteil - so wie Bleiglanz bereits gesagt hat, """= verzicht auf Generics, toller Vorschlag""

 

[Bleiglanz]

Es ist durchaus möglich anhand des Codes zu bestimmen,
ob sich Konflikte ergeben oder nicht

Ganz im Gegenteil, es völlig unmöglich

Ich finde den Cast einfach nur überflüssig, da er selbstverständlich ist.

Schon klar, du gehst davon aus, dass der lvalue bestimmt was von der rechten Seite kommt, d.h. der Compiler könnte in der Zeile

Foo f = mylist.get(0); // javac macht einfach (Foo) list.get(0); draus

den Cast einfach "automatisch einfügen", leider hat das überhaupt nichts mit generics zu tun (bei denen es ja im Collection Bereich vor allem um das EINFÜGEN geht)!

Dein Vorschlag würde nur bei völlig trivialen Codezeilen wie der obigen eine minimale Einsparung an Schreibarbeit bringen.