Konstruktor-Aufruf nun mit oder ohne Typ?

[Guest]

Hallo,

bei meinen ersten Gehversuchen mit Generics bin ich auf folgende Sache gestoßen.

Ich habe mir ein Beispiel definiert (Presse, die Saft aus Früchten pressen kann, die ihrerseits auspressbar sind ;-))

public class Presse<E extends Fruit & IPressable> {

    public Presse() {
    }

    public void startPressing(E fruit) {
         fruit.press();
    }
}

passende Frucht:

public class Orange extends Fruit implements IPressable {...}

Das klappt auch toll. Allerdings bin ich über die Konstruktion des Presse-Objekts etwas ins Stutzen gekommen:

Laut meinem Buch müsste es heißen:

Presse<Orange> p = new Presse<Orange>();

(funktioniert)

Allerdings funktioniert auch:

Presse<Orange> p = new Presse();

Ich hätte nun gerne gewusst, was richtig ist (Spec gibt's ja leider noch nicht zum Download) - oder ist das irgendwie so ein Bequemlichkeits-Ding?

Danke für Eure Hinweise!

Gruß,

Karl

P.S.: Ich habe extra getestet, ob das Verhalten identisch ist, indem ich versucht habe, in der Orangenpresse eine Zitrone auszupressen - korrekte Fehlermeldung in beiden Fällen, dass Zitronen eben keine Orangen sind ;-).

 

[Beni]

Das erste ist korrekt, das zweite müsste eine Warnung des Compilers geben.

 

[Karl]

Hallo Beni,

Danke!
Für die JDK-1.5-Spielereien habe ich mir neben Eclipse netbeans installiert, weil die 1.5 voll unterstützen.
Vielleicht habe ich da was übersehen, was die Warnungen angeht.

Gruß,

Karl

 

[bygones]

eclipse unterstützt ab 3.1M3 nahezu auch alle 1.5 features....

zu dem zweiten Bsp. du änderst die parametrisierte Frucht wieder zum RawType, was ansich unsinnig ist, warum dann der Parameter.. Der Compiler spuckt hier dann ein Typ Safety Warnung aus

 

[foobar]

eclipse unterstützt ab 3.1M3 nahezu auch alle 1.5 features....

Was wird denn noch nicht unterstützt?

 

[bygones]

Status of J2SE 5.0 features
The changes to the Java tools to support J2SE 5.0 (aka 1.5) are coming along nicely. The Eclipse Java compiler now supports the following additional new features of J2SE 5:

* enumerations
* static imports
* varargs

Generics, enhanced for loops, and hexadecimal floating point literals were supported in M2, although the support for generic types has improved significantly since then. The other language additions - annotations and autoboxing - make it past the parser, but are not yet being processed any deeper than that. Support for these other new language features will be introduced in future 3.1 milestones. (As of M3, the Eclipse Java compiler is passing 97.95% of the JCK 1.5 compliance tests, up from 96.8% for M2. Only 223 more tests to go, out of 10863.)

In order to work with any of the new language features you must set the Java project's compiler compliance level to 1.5 (Java Compiler > Compliance and Classfiles > Compiler compliance level > 1.5) and configure the Java build path with the system libraries from an installed 1.5 JRE.

 

[Bleiglanz]

Presse<Orange> p = new Presse();

Sollte gehen, aber mit der üblichen Warnung, die erste Variante ist natürlich richtig.

oder ist das irgendwie so ein Bequemlichkeits-Ding?

Ja! BTW: das liegt am "Erasure", Presse<Orange> ist zur Laufzeit nichts anderes als Presse; ohne dieses Feature liessen sich bestehende Bibliotheken kaum mit den neuen Generics verwenden:. man soll ja schreiben dürfen

List<Birnen> = altesLegacyObject.getTheBirnen();
 // gibt java.util.List zurück

 

[bygones]

trotzdem sind generics weit mehr als ein "Bequemlichkeits-Ding"... das wird zum einen dadurch gedacht, als dass man Generics als reine "Nicht-mehr-Casten-Müssen" Sache ansieht....

einfachstes beispiel ist. Bisher kann es passieren, dass man eine fremde Methode nutzt, die eine Map zurückgibt. Nun liegt es an dir zu schauen, was ist in der map drinnen und damit gefahr zu laufen das ganze programm durch einen ClassCastException scheitern zu lassen...

Mit generics bekommst du nun einen Map<String,List<String>> zurück und somit ist sofort klar was sich in dieser map befindet !!
D.h. die Schnittstellen definitionen werden klarer

(ganz abgesehen von den Template möglichkeiten durch generics)

 

[Bleiglanz]

@deathbyaclown

ich denke, mit Bequemlichkeitsding war gemeint, dass

Presse<Orange> p = new Presse();

funktioniert

ist aber auch ein Seiteneffekt des Erasure

 

[Karl]

Hallo Bleiglanz,

genau, so war's gemeint - und dank Deines Beispiels leuchtet mir die Sache jetzt auch ein ;-)
Der Compiler lässt es hier durchgehen, weil er es bei Legacy-Code ja so oder so dulden muss.

Mein erster Eindruck ist, dass Generics die Probleme von der Laufzeit (bisher dubiose ClassCastExceptions, die man mühsamst debuggen muss) auf die Compile-Zeit verlegt (in Zukunft bei komplexen Konstruktionen "Knobeltime mit eckigen Klammern" ;-)).
Das ist schon ein Vorteil, zumal die Kosten für Fehlerbeseitigung automatisch sinken, je früher er erkannt wird.
An der Komplexität bei verschachtelten Deklarationen kommt man halt nicht vorbei.


Gruß,

Karl