# Eure Wunschliste für Java 7?



## jollyroger (26. Jun 2008)

Moin, 

ich hab kein derartiges Thema hier im Forum gefunden, deshalb meine Frage:

Was wünscht ihr euch für java 7?

Wenn ich mir die bisherigen JSRs anschaue:

-> http://www.tutego.com/java/jdk7-Java-SE-7.htm

 ist da leider nichts von dem drin was ich gerne hätte....:-/

Meine Wunschliste:

- Ein modifier der „private protected“ ausdrückt
- switch case mit Strings (ohne Umweg über enums)
- Operator overloading (aber nur für ein definiertes Set, nicht für alle!)
- Umbenennung unsinnig benannter exceptions (NullPointerException, RuntimeException [alle exceptions sind zur runtime!])
- continuations


----------



## jollyroger (26. Jun 2008)

Moin, 

ich hab kein derartiges Thema hier im Forum gefunden, deshalb meine Frage:

Was wünscht ihr euch für java 7?

Wenn ich mir die bisherigen JSRs anschaue:

-> http://www.tutego.com/java/jdk7-Java-SE-7.htm

 ist da leider nichts von dem drin was ich gerne hätte....:-/

Meine Wunschliste:

- Ein modifier der „private protected“ ausdrückt
- switch case mit Strings (ohne Umweg über enums)
- Operator overloading (aber nur für ein definiertes Set, nicht für alle!)
- continuations
- Umbenennung unsinnig benannter exceptions (NullPointerException, RuntimeException [alle exceptions sind zur runtime!])
- Umbenennung aller javax.*-Pakete zu java.*

Mir ist klar, das die letzten beiden Punkte jede Rückwärtskompatibilität brechen würde, aber mein Gott, irgendwann muss man halt mal alte Zöpfe abschneiden.....

EDIT: Sorry, hab aus Versehen auf "neue Antwort" statt auf "editieren" geklickt....


----------



## Saxony (26. Jun 2008)

Hallo,

ich hätte gerne, dass Java sofort weiß was ich proggen möchte!
Also ich schreib zum Beispiel public boolean machIrgendwas und Java macht gleich den Rest der Methode dazu - das wäre fein 

Aber um beim Thema zu bleiben:

Ich hätte gerne, wie in einem vorigen Thread festgestellt so etwas:

if ch in['a'..'z'] { sysout("Gott sei dank geht das endlich"); }

bye euer Saxony


----------



## maki (26. Jun 2008)

> - Ein modifier der „private protected“ ausdrückt


Was soll denn "private protected" sein?



> - switch case mit Strings (ohne Umweg über enums)


Brauch ich nicht 



> - Operator overloading (aber nur für ein definiertes Set, nicht für alle!)



Bin ausdrücklich gegen Oprator Überladungen.



> - continuations


Was ist das?



> - Umbenennung unsinnig benannter exceptions (NullPointerException, RuntimeException [alle exceptions sind zur runtime!])


Was soll an "NullPointerException" schlecht sein?
Runtime heisst übrigens etwas anderes in diesem Context, nämlich VM.



> - Umbenennung aller javax.*-Pakete zu java.*


Wozu soll das gut sein?
Die Standard API ist doch sowieso schon überladen.


----------



## jollyroger (26. Jun 2008)

> Zitat:
> - Ein modifier der „private protected“ ausdrückt
> 
> Was soll denn "private protected" sein?



Hat es dich noch nie gestört, das mit protected versehene fields auch package-weit sichtbar sind? Genau das ist damit gemeint.....



> - switch case mit Strings (ohne Umweg über enums)
> 
> Brauch ich nicht icon_smile.gif



Fein, deswegen steht es ja auch in *meiner* Wunschliste. Mit enums find ichs halt extrem unschön.



> - Operator overloading (aber nur für ein definiertes Set, nicht für alle!)
> 
> 
> Bin ausdrücklich gegen Oprator Überladungen.



Ich nicht..... :wink: 



> - continuations
> 
> Was ist das?



Kuck dir mal Rife an: http://rifers.org/wiki/display/RIFE/Web+continuations



> What are continuations?
> 
> These constructs are inspired from Scheme and basically contain all information about a specific program location and the local method variables. Using this information, the application is able to create an interruption in program execution (this is RIFE-specific) continue later at the exact same location as if nothing happened.
> 
> ...





> Zitat:
> 
> - Umbenennung unsinnig benannter exceptions (NullPointerException, RuntimeException [alle exceptions sind zur runtime!])
> 
> ...



NullReferenceException wäre wohl treffender, es sei denn du hast einen Weg gefunden Pointer in Java zu verwenden...



> - Umbenennung aller javax.*-Pakete zu java.*
> 
> Wozu soll das gut sein?
> Die Standard API ist doch sowieso schon überladen.



javax.* ist doch nur noch aus historischen Gründen mit dem "x"....

Edit: Gerade noch folgendes bei "diskutierten Änderungen" gesehen:



> Im switch nicht nur int, sondern auch Strings


----------



## Wildcard (26. Jun 2008)

Ein switch ist ja nicht einfach eine andere Schreibweise für eine Menge von ifs, sondern wird in eine sehr schnelle Sprungtabelle umgesetzt. Das funktioniert nur mit primitiven Datentypen.

Operatorüberladung ist pfui.

Das einzige was ich mir spontan einfallen würde ist ein Base64 Encoder/Decoder und ein paar mehr Swing Widgets.


----------



## AlArenal (26. Jun 2008)

Eine Referenz ist ein Pointer auf eine Instanz. Der Begriff der Referenz hat sich in Java aber durchgesetzt, damit nicht jeder Hoshi krampfhaft versucht Zeigerarithmetik ans Laufen zu bekommen, weil er bei "Pointer" direkt an C denkt.


----------



## Niki (26. Jun 2008)

```
Hat es dich noch nie gestört, das mit protected versehene fields auch package-weit sichtbar sind? Genau das ist damit gemeint.....
```

Meine Attribute sind *IMMER* private und nur über Methoden änderbar. So solls auch sein.


----------



## Saxony (26. Jun 2008)

Wildcard hat gesagt.:
			
		

> und ein paar mehr Swing Widgets.



Ja richtig, das wäre fein! SwingX joins JDK 7! 

bye Saxony


----------



## maki (26. Jun 2008)

> Hat es dich noch nie gestört, das mit protected versehene fields auch package-weit sichtbar sind? Genau das ist damit gemeint.....


Absolut nicht, wenn ich das nicht möchte, mache ich sie nicht protected, sollten meistens sowieso privat sein, protected nur mit Grund, nicht einfach so... siehe Post von Niki.



> Fein, deswegen steht es ja auch in meiner Wunschliste. Mit enums find ichs halt extrem unschön.


Wie Wildcard bereits sagte, kann das in der jetzigen Form (seit C schon) nur sinnvoll mit primitiven Zahlen umgesetzt werden.



> Ich nicht..... icon_wink.gif


Müssen ja nicht alles gleich sehen, das abschaffen der Op. Überladungen sehe ich als echten Vorteil in java.

Naja, wenn wir schon dabei sind Wünsche zu äussern, wäre mein Wunsch das entgültige abschaffen von altlasten wie Vector etc, ist längst überfällig imho.


----------



## SlaterB (26. Jun 2008)

Niki hat gesagt.:
			
		

> Meine Attribute sind *IMMER* private und nur über Methoden änderbar. So solls auch sein.



für Methoden gilt aber das gleiche Spiel:
Methoden nur für die Subklassen sind auch im ganzen Package sichtbar,

stört mich auch in seltenen Fällen, 
wahrscheinlich ein Hinweis, die Klassen besser aufzutrennen in noch mehr packages


----------



## Niki (26. Jun 2008)

Das ist schon richtig, aber in Methoden habe ich auf jeden Fall mehr Kontrolle.


----------



## tfa (26. Jun 2008)

jollyroger hat gesagt.:
			
		

> -> http://www.tutego.com/java/jdk7-Java-SE-7.htm
> 
> ist da leider nichts von dem drin was ich gerne hätte....:-/


Eine vollständigere Liste findest du hier: java.dzone.com/news/java-7-predictions
Switch mit Strings steht da z.B. auch drin, obwohl Enums völlig ausreichend sind.


> - Umbenennung unsinnig benannter exceptions (NullPointerException, RuntimeException [alle exceptions sind zur runtime!])
> - Umbenennung aller javax.*-Pakete zu java.*
> 
> Mir ist klar, das die letzten beiden Punkte jede Rückwärtskompatibilität brechen würde, aber mein Gott, irgendwann muss man halt mal alte Zöpfe abschneiden.....


Das wird nie passieren. Dann kannst du alles wegwerfen und von vorne anfangen - oder Java 7 ignorieren.
Die trauen sich ja nicht mal, Vector, Stack, Hashtable usw. deprecated zu machen.

Ansonsten finde ich Closures und ARM-Blöcke noch interessant, obwohl erstere wahrscheinlich ziemlich viel Komplexität mitbringen werden.


----------



## Saxony (26. Jun 2008)

SlaterB hat gesagt.:
			
		

> wahrscheinlich ein Hinweis, die Klassen besser aufzutrennen in noch mehr packages



Hmm, oder andersrum nur noch: import java.*;

Lustig ist ja das hier:
XML Support No - 0% Not a chance 

bye Saxony


----------



## jollyroger (26. Jun 2008)

> Ein switch ist ja nicht einfach eine andere Schreibweise für eine Menge von ifs, sondern wird in eine sehr schnelle Sprungtabelle umgesetzt. Das funktioniert nur mit primitiven Datentypen.



Das ist mir klar, es geht einfach um eine bessere Lesbarkeit == bessere Wartbarkeit.



> Eine Referenz ist ein Pointer auf eine Instanz. Der Begriff der Referenz hat sich in Java aber durchgesetzt, damit nicht jeder Hoshi krampfhaft versucht Zeigerarithmetik ans Laufen zu bekommen, weil er bei "Pointer" direkt an C denkt.



Aber genau nach dem Argument ist eine "NullPointerException" eben irreführend....



> Meine Attribute sind IMMER private und nur über Methoden änderbar. So solls auch sein.



Es gibt aber Fälle, wo das zu äußerst unschönen Konstruktionen führt, und genau für diese hätte ich gerne erwähntes Feature....



> Müssen ja nicht alles gleich sehen, das abschaffen der Op. Überladungen sehe ich als echten Vorteil in java.



Ich "eigentlich" auch, aber für bestimmtes Set (z.B. +,-,*,/) fände ich es vorteilhaft, weil lesbarer als endlose Methodenverknüpfungen....



> Naja, wenn wir schon dabei sind Wünsche zu äussern, wäre mein Wunsch das entgültige abschaffen von altlasten wie Vector etc, ist längst überfällig imho.



Ich sekundiere.... :wink:


----------



## byte (26. Jun 2008)

Ich wünsche mir eine Überarbeitung der Swing zugrunde liegenden Konzepte, Daten an Komponenten zu binden (TableModel, TreeModel, ...). Diese ganzen Konzepte, die größtenteils aus Java 1.2 Zeiten stammen, sind einfach nicht mehr state of the art. Wie es richtig geht, zeigen ja andere Libs (siehe JFace von SWT). Einiges wurde durch SwingX schon verbessert, aber das geht noch besser.
In diesem Zusammenhang könnte man auch direkt die Palette an Komponenten erweitern.

Ich habe gelesen, dass ein paar Sachen aus SwingX übernommen werden in Java 7 (ich meine, es waren Filter). Aber das ist nur ein Tropfen auf den heissen Stein. Da muss dringend mehr passieren, sonst wird Swing im Desktopbereich nie den Anschluß finden. Das Swing Application Framework geht auf jeden Fall schonmal in die richtige Richtung.


----------



## AlArenal (26. Jun 2008)

jollyroger hat gesagt.:
			
		

> > Eine Referenz ist ein Pointer auf eine Instanz. Der Begriff der Referenz hat sich in Java aber durchgesetzt, damit nicht jeder Hoshi krampfhaft versucht Zeigerarithmetik ans Laufen zu bekommen, weil er bei "Pointer" direkt an C denkt.
> 
> 
> 
> Aber genau nach dem Argument ist eine "NullPointerException" eben irreführend....



Für wen? Für Leute, die nicht wissen, was sie tun? 

Dann will ich aber auch, dass Zeilennummern eingeführt werden...


----------



## Guest (26. Jun 2008)

Saxony hat gesagt.:
			
		

> if ch in['a'..'z'] { sysout("Gott sei dank geht das endlich"); }




```
if (Character.isLowerCase(ch))
	System.out.println("Das ging schon immer");
```


----------



## maki (26. Jun 2008)

Anonymous hat gesagt.:
			
		

> Saxony hat gesagt.:
> 
> 
> 
> ...


Ja, ging schon immer, alternativ dazu 

if ( ch >= 'a' || ch <= 'z') {
...
}


----------



## Saxony (26. Jun 2008)

Aha und wenn ich:

if ch in['d'..'q'] machen will ?
Oder auch if i in [4..8].

Ums kurz zu machen, ich will, dass man einen aktuellen Wert derart mit einer Menge vergleichen kann, dass gilt:

var element der Menge -> ja oder nein

Ohne irgendwelchen gestelzten Konstrukte über Character Klasse oder mit zig bool'schen Ausdrücken!

und um die Sache noch zu übertreiben:

if d in[3.45435..4.35445] { sysout("aha mit floating point is auch nicht schlecht"); }

Und um auch dem anderen Vorredner(maki) den Wind aus den Segeln zu nehmen:

if ch in['a','d','g','k','m','t','1'..'4', '6'..'8','u','w'..'z'] { sysout("das if dazu will ich sehen - hehe") }

bye Saxony


----------



## SlaterB (26. Jun 2008)

if (Helper.in(ch,'a','d','g','k','m','t','u','x','y','z')) { 
sysout("nix einfacher als das") 
}

oder sogar noch schöner
if (Helper.in(ch,"adgkmtuxyz")) { 
sysout("nix einfacher als das") 
}

was uns wieder zu gewissen String-Operationen bringt


----------



## Saxony (26. Jun 2008)

Na sag ma red ich hier im Kreis oder wie?

ICH WILL, dass so etwas nativ von der Sprache unterstützt wird! Nicht über Character, mit Hilfe von zig bool'schen Ausdrücken oder wie jetzt sogar noch vorgeschlagen wird über static Methoden einer superduper Helper Klasse mit variabler Argumentenzahl!

Hier war nach Wünschen gefragt und so wünsche ich mir das. <- Punkt

bye Saxony


----------



## maki (26. Jun 2008)

> Und um auch dem anderen Vorredner(maki) den Wind aus den Segeln zu nehmen:
> 
> if ch in['a','d','g','k','m','t','1'..'4', '6'..'8','u','w'..'z'] { sysout("das if dazu will ich sehen - hehe") }


Maki segelt mit dem Wind im Rücken davon und ruft noch "regex" beim überholen


----------



## Saxony (26. Jun 2008)

maki hat gesagt.:
			
		

> Maki segelt mit dem Wind im Rücken davon und ruft noch "regex" beim überholen



siehe mein letztes Post! auch regex will ich da nicht haben! 
Kanns ja meinetwegen intern so umstricken, aber ich will in meinem Source if ch in[wasauchimmer] stehen haben!

Seid lieber froh, dass ich von der PASCAL-Schiene her komme und nicht mit Basic laufen gelernt habe! 

bye Saxony


----------



## Oni (26. Jun 2008)

maki hat gesagt.:
			
		

> > Und um auch dem anderen Vorredner(maki) den Wind aus den Segeln zu nehmen:
> >
> > if ch in['a','d','g','k','m','t','1'..'4', '6'..'8','u','w'..'z'] { sysout("das if dazu will ich sehen - hehe") }
> 
> ...



   :toll: 


Was habt ihr eigentlich gegen die Klassen Vector & Hashtable? ArrayList und HashMap sind ja nicht synchronisiert also nicht unbedingt ein ersatz dafür.


----------



## SlaterB (26. Jun 2008)

Saxony hat gesagt.:
			
		

> Hier war nach Wünschen gefragt und so wünsche ich mir das. <- Punkt


nana,
gefragt war doch wohl
> das if dazu will ich sehen 
oder nicht? dann darf man das auch mal posten


----------



## maki (26. Jun 2008)

> Was habt ihr eigentlich gegen die Klassen Vector & Hashtable? ArrayList und HashMap sind ja nicht synchronisiert also nicht unbedingt ein ersatz dafür.


Beide, Hashtable und Vector sind überreif für den Schrott (deprecation), weil sie nicht nur das Map bzw. List interface implmentieren, sondern auch noch überbleibsel aus der pre-Collections Ära.

Wenn ich Map/List synchronisiert brauche nehme ich http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collections.html#synchronizedList(java.util.List)

Vector/Hashmap bieten nix sinnvolles was das Collections-Framework nicht auch bietet...

@ Saxony:
nun ja, wenn dass dein Wunsch ist, muss man das wohl respektieren.


----------



## Saxony (26. Jun 2008)

maki hat gesagt.:
			
		

> @ Saxony:
> nun ja, wenn dass dein Wunsch ist, muss man das wohl respektieren.



Nu! *liebgugg*

Übrigens ist mir gerade aufgefallen, dass meine Signatur Flagge falsch ist! Der letzte Sektor muss 255,204,0 haben und nicht 255,255,0! Nuja Sachen gibts - hehe 

bye Saxony


----------



## Marco13 (26. Jun 2008)

Ein Wunsch: Generics in Swing! TreeNode<UserObjectType> und so.... Dürfte aber für Java7 (und vermutlich noch bis Java 10 oder so....) zu aufwändig sein.


----------



## ARadauer (26. Jun 2008)

im J2ee bereich könnte das ganze deployment thema vereinfacht werden. wir haben hier eine eigene abteilung die für diese themen zuständig ist. in php lad ich die files rauf - fertig. bei fetten j2ee anwendungen muss ich in zig xml files wirre konfigs vornehmen.

ein paar einfache dinge in swing könnten verbessert werden, binding usw...


----------



## ARadauer (26. Jun 2008)

> Naja, wenn wir schon dabei sind Wünsche zu äussern, wäre mein Wunsch das entgültige abschaffen von altlasten wie Vector etc, ist längst überfällig imho.


das wirds nie spielen, thema abwärtskompatibilität, was es gegeben hat bleibt. es gibt anscheinden api klassen mit mehr depricated methoden als andere....


----------



## maki (26. Jun 2008)

> im J2ee bereich könnte das ganze deployment thema vereinfacht werden. wir haben hier eine eigene abteilung die für diese themen zuständig ist. in php lad ich die files rauf - fertig. bei fetten j2ee anwendungen muss ich in zig xml files wirre konfigs vornehmen.


In JEE (5) ist es etwas besser geworden, ansonsten empfiehlt sich ein gutes Build Tool, zB. Maven 2.


----------



## byte (26. Jun 2008)

ARadauer hat gesagt.:
			
		

> im J2ee bereich könnte das ganze deployment thema vereinfacht werden. wir haben hier eine eigene abteilung die für diese themen zuständig ist. in php lad ich die files rauf - fertig. bei fetten j2ee anwendungen muss ich in zig xml files wirre konfigs vornehmen.



Was setzt Ihr denn so ein? EJB <3 ? 

JEE ist halt nun mal etwas mehr als PHP. :roll: Und wie wirr die Konfiguration am Ende ist, hängt von der eingesetzten Technologie ab. Wenn Du z.B. ein DispatcherServlet in die web.xml hängst (z.B. mit Spring), dann stehen nur ne handvoll Zeilen in der web.xml.

Aber das geht jetzt eher in die Richtung einer JEE 6 Wunschliste.  Ich freue mich auf jeden Fall auf die JEE 6 Profiles. Das dürfte einiges bewegen.


----------



## jollyroger (26. Jun 2008)

> im J2ee bereich könnte das ganze deployment thema vereinfacht werden. wir haben hier eine eigene abteilung die für diese themen zuständig ist.



Naja, 

aber genau diese Problematik wurde ja durch Annotations entschärft.....

Man vergleiche nur mal das xml-Pendant zu z.B. @RolesAllowed("foo")....ich finde, das ist schon erheblich einfacher geworden.


----------



## Janus (26. Jun 2008)

ein package hierarchy down scope wäre nicht schlecht. also ein sichtbereich, der sub-packages zugriff auf die klase erlaubt, aber packages oberhalb oder neben dem definierten nicht.

com.foo.SomeClass
com.foo.bar.SomeOther darf auf SomeClass zugreifen
com.baz.OutClass aber nicht

sowas lässt sich derzeit nur mit irgendwelchen build tools hinbekommen.

type erasure für arrays wäre auch ne feine sache.

was ich weiterhin *niemals* in java sehen möchte:
- operator-überladung
- templates


----------



## Wildcard (26. Jun 2008)

Janus hat gesagt.:
			
		

> ein package hierarchy down scope wäre nicht schlecht. also ein sichtbereich, der sub-packages zugriff auf die klase erlaubt, aber packages oberhalb oder neben dem definierten nicht.


Es gibt keine sub packages, es gibt nur packages  :wink:


----------



## Janus (26. Jun 2008)

genau mit der tradition will ich ja brechen


----------



## foobar (27. Jun 2008)

Zum Thema Ranges und Closures in Java  finde ich das hier ganz interessant: http://gleichmann.wordpress.com/2008/01/21/declarative-programming-a-range-type-for-java/
http://gleichmann.wordpress.com/2008/02/10/blocks-an-alternative-for-closures/
http://gleichmann.wordpress.com/2008/01/13/building-your-own-literals-in-java-lists-and-arrays/


----------



## thE_29 (27. Jun 2008)

@Janus: Dir ist schon klar das generisches Verhalten ein ähnliches Konzept zu Templates ist?

Und ich würde mich über Operatorenüberladungen sehr freuen


----------



## tfa (27. Jun 2008)

Generics und Templates sehen zwar ähnlich aus und haben ähnliche Zwecke, konzeptionell sind sie aber sehr unterschiedlich.


----------



## foobar (27. Jun 2008)

Meine Wunschliste für Java 7:

- Closures
- Überarbeitung der Exceptionhierarchie z.b. SqlExceptions von RuntimeException ableiten
- Operatorüberladung für BigDecimal
- Eine Möglichkeit Groovy oder andere Scriptsprache inline auszuführen so wie man das mit Assembler in C macht
- Reimplementierung der Enumklasse. Enums sind super, aber sobald man mehr als einen int-Value benötigt wirds lästig. Man kann sich keine abstrakte Oberklasse für Enums machen.
- Alle Widgets von SwingX in Swing integrieren
- Superpackages um Schluss mit der Jarhölle zu machen siehe Osgi
- Regexintegration wie in Scriptsprachen

Ausserdem wünsche ich mir, daß alle Betriebssysteme standardmäßig mit dem neuesten JRE ausgeliefert werden und sich automatisch updaten.


----------



## byte (27. Jun 2008)

foobar hat gesagt.:
			
		

> - Reimplementierung der Enumklasse. Enums sind super, aber sobald man mehr als einen int-Value benötigt wirds lästig. Man kann sich keine abstrakte Oberklasse für Enums machen.


Vermisse ich nicht wirklich, zumal Du notfalls mit Interfaces und Komposition das gleiche erreichst.


----------



## SlaterB (27. Jun 2008)

eine leichte kleine Enum ist eh immer zu begrüßen,
im Zweifel Map<Enum,dickes Objekt>
die Map ist dann ein statisches Singleton  :bae:


----------



## diggaa1984 (27. Jun 2008)

mal ne dumme frage:

les hier das erste ma was von closures ... und dachte mir ich google mal.
gut getan, gefunden. Es gibt ja da bereits tutorials diesbezüglich in Java, was genau wünscht ihr euch da quasi noch? ^^ 

Hab nu nich ewig viele blogs gelesen die da irgendwas bezüglich closures diskutieren, aber für mich siehts grad mal so aus, dass sie ja schon umsetzbar sind.


----------



## Beni (27. Jun 2008)

foobar hat gesagt.:
			
		

> - Reimplementierung der Enumklasse. Enums sind super, aber sobald man mehr als einen int-Value benötigt wirds lästig. Man kann sich keine abstrakte Oberklasse für Enums machen.


Hä? Was? Gib dem Enum eine Referenz auf dein Objekt und gut ist :wink:

Achja, Superpackages wären toll. Ansonsten hoffe ich, dass nicht zuviel reinkommt - einen C++ *kann alles niemand versteht es* - Klon brauche ich nicht :wink:


----------



## foobar (27. Jun 2008)

Vielleicht habe ich mich etwas unklar ausgedrückt. Ich habe viele enums die ungefähr so aussehen:


```
public enum Gebuehrart implements SearchableEnum
    {
        Prozent(0, Messages.getString("ChargeBean.lblProzent")), //$NON-NLS-1$
        Betrag(1, Messages.getString("ChargeBean.lblBetrag")), //$NON-NLS-1$
        Brutto(1, Messages.getString("ChargeBean.lblBrutto")), //$NON-NLS-1$
        Netto(2, Messages.getString("ChargeBean.lblNetto")), //$NON-NLS-1$
        Staffel(3, Messages.getString("ChargeBean.lblStaffel")); //$NON-NLS-1$

        private int    value;
        private String description;

        Gebuehrart(int value, String description)
        {
            this.value = value;
            this.description = description;
        }

        public int getValue()
        {
            return value;
        }

        public String getDescription()
        {
            return description;
        }

        public static String[] getAsArray()
        {
            String[] out = new String[values().length];
            for (int i = 0; i < values().length; i++)
            {
                out[i] = values()[i].getDescription();
            }
            return out;
        }

        public static Gebuehrart getGebuehrartByID(int id)
        {
            for (Gebuehrart m : values())
            {
                if (m.getValue() == id)
                {
                    return m;
                }
            }
            return null;
        }

        @Override
        public String toString()
        {
            return description;
        }
    }
```

Jetzt hätte ich gerne eine Enumoberklasse, die mir schon einen Kostruktor mit int, String bereit stellt und die getMyTypeById-Methode. Im Moment lässt sich das mit den JDK enums aber nicht lösen. Die einzige Möglichkeit wäre wieder auf das Typesafenum-Pattern zurückzugreifen.
Im Apache commons Projekt gibts auch eine enum-Klasse, von der man erben kann aber ich fände es viel schöner, wenn das mit den JDK enums funzen würde.


----------



## tfa (27. Jun 2008)

diggaa1984 hat gesagt.:
			
		

> Hab nu nich ewig viele blogs gelesen die da irgendwas bezüglich closures diskutieren, aber für mich siehts grad mal so aus, dass sie ja schon umsetzbar sind.


Es gibt verschiedene Entwürfe zu Closure in Java, von einfach bis kompliziert. Wahrscheinlich hast du Diskussionen über diese Entwürfe gelesen.


----------



## byte (27. Jun 2008)

foobar hat gesagt.:
			
		

> ---SNIP---
> 
> Jetzt hätte ich gerne eine Enumoberklasse, die mir schon einen Kostruktor mit int, String bereit stellt und die getMyTypeById-Methode. Im Moment lässt sich das mit den JDK enums aber nicht lösen. Die einzige Möglichkeit wäre wieder auf das Typesafenum-Pattern zurückzugreifen.
> Im Apache commons Projekt gibts auch eine enum-Klasse, von der man erben kann aber ich fände es viel schöner, wenn das mit den JDK enums funzen würde.



Würde ich einfach so machen:


```
public enum Gebuehrart implements SearchableEnum {
   PROZENT(0, "Prozent"), 
   BETRAG(1, "Betrag"), 
   BRUTTO(1, "Brutto"), 
   NETTO(2, "Netto"), 
   STAFFEL(3, "Staffel");

   private int value;
   private String description;

   Gebuehrart(int value, String description) {
      this.value = value;
      this.description = description;
   }

   public String getDescription() {
      return description;
   }

   public int getValue() {
      return value;
   }

   @Override
   public String toString() {
      return description;
   }
}
```


```
public interface SearchableEnum {
   public int getValue();
   public String getDescription();
}
```


```
public class Util {
   public static <T extends SearchableEnum> String[] toArray(Class<T> enumType) {
      T[] values = enumType.getEnumConstants();
      String[] out = new String[values.length];
      for (int i = 0; i < values.length; i++) {
         out[i] = values[i].getDescription();
      }
      return out;
   }

   public static <T extends SearchableEnum> T getByID(Class<T> enumType, int id) {
      for (T t : enumType.getEnumConstants()) {
         if (t.getValue() == id) {
            return t;
         }
      }
      return null;
   }
}
```


----------



## diggaa1984 (27. Jun 2008)

aso ok, da stand was von tutorials als überschrift, aber vermutlich doch nur als "so könntes ma aussehen" .. sehr verwirrend ^^


----------



## ARadauer (27. Jun 2008)

gibt da viele diskussionen bezüglich Closures. ich bin der meinung das es nicht gerade ein einfaches konzept ist, dass die sprach unnötig verkompliziert... ich bin dagegen


----------



## foobar (27. Jun 2008)

@byto Danke für den Beitrag. Das würde auf jedenfall erstmal den redundanten Code in meinen  enums entfernen. 

@ARadauer Ich finde Closures machen das Leben einfacher, weil man sich viel Tipparbeit spart. Wenn eine Closure kompatibel zu einer inneren Klasse ist, kann man immer noch selber entscheiden was man verwenden möchte. Oft benutzt man eine innere Klasse z.b.  im ActionListener in Swing oder SelectionListener in Swt nur dazu eine Methode der Elternklasse aufzurufen. Das finde ich echt nervig, weil das den Code unnötig aufbläht. Es wäre doch viel schöner wenn man sowas:


```
myButton.addSelectionListener(new SelectionAdapter()
{
     public void widgetSelected(SelectionEvent e)
     {
         doSomething();
     }
});
```

durch sowas ersetzen kann:


```
myButton.addSelectionListener({ => doSomething(); });
```


----------



## AlArenal (27. Jun 2008)

Zu dumm nur, dass so ein Interface mehr als eine Methode haben kann / muss..


----------



## byte (27. Jun 2008)

foobar hat gesagt.:
			
		

> @byto Danke für den Beitrag. Das würde auf jedenfall erstmal den redundanten Code in meinen  enums entfernen.


NP, du musst nur darauf achten, dass die übergebene SearchableEnum-Klasse auch wirklich eine Enum ist, sonst liefert enumType.getEnumConstants() null. Habs auf die schnelle nicht hinbekommen, wie man Enum und SearchableEnum generisch vereint.


----------



## SlaterB (27. Jun 2008)

public static <T extends Enum<T> & SearchableEnum> T getByID(Class<T> enumType, int id) {


so wie es ja auch schon in der Enum-Klasse gibt:

```
/**
     * Returns the enum constant of the specified enum type with the
     * specified name.  The name must match exactly an identifier used
     * to declare an enum constant in this type.  (Extraneous whitespace
     * characters are not permitted.) 
     *
     * @param enumType the <tt>Class</tt> object of the enum type from which
     *      to return a constant
     * @param name the name of the constant to return
     * @return the enum constant of the specified enum type with the
     *      specified name
     * @throws IllegalArgumentException if the specified enum type has
     *         no constant with the specified name, or the specified
     *         class object does not represent an enum type
     * @throws NullPointerException if <tt>enumType</tt> or <tt>name</tt>
     *         is null
     * @since 1.5
     */
    public static <T extends Enum<T>> T valueOf(Class<T> enumType,
                                                String name) {
        T result = enumType.enumConstantDirectory().get(name);
        if (result != null)
            return result;
        if (name == null)
            throw new NullPointerException("Name is null");
        throw new IllegalArgumentException(
            "No enum const " + enumType +"." + name);
    }
```


----------



## byte (27. Jun 2008)

Cool, kannte ich bisher gar nicht, dass man mehrere Typen mit & verknüpfen kann.


----------



## Janus (28. Jun 2008)

closures sind meiner ansicht nach in java überflüssig. jede objektorientierte sprache kann sich da wunderbar mit anderen konstrukten behelfen. von mir aus können ein paar neue basisklassen in die standard lib übernommen werden, die einen bei sowas unterstützten, aber ich halte wirklich wenig davon, java features zu spendieren, die bereits umsetzbar sind.

ok, "echte" enums waren tatsächlich mal überfällig, aber java soll kein sprachmonster werden.

ich hab mir z.b. an manchen stellen tatsächlich mehrfachvererbung gewünscht, weil es einige probleme wunderbar schnell und einfach gelöst hätte. aber da java sowas nicht unterstützt, musste ich mir was anderes ausdenken und das hat in jedem fall zu übersichtlicherem code geführt. dass java "so wenig" kann, ist ein segen.


----------



## tfa (28. Jun 2008)

Janus hat gesagt.:
			
		

> closures sind meiner ansicht nach in java überflüssig.


Klar sind Closures überflüssig. Genauso überflüssig wie Generics, Enhanced For-Loops, Enums und das Concurrency-Framework. Software kann man auch ohne all dies schreiben, aber es könnte einem das Leben leichter machen, wenn  die Programme dadurch lesbarer, übersichtlicher und wartbarer werden. Hoffentlich trifft das dann auchmal für Closures zu, wenn diese nicht zu kompliziert umgesetzt werden. Die Gefahr besteht allerdings, da geb ich dir recht.



> jede objektorientierte sprache kann sich da wunderbar mit anderen konstrukten behelfen. von mir aus können ein paar neue basisklassen in die standard lib übernommen werden, die einen bei sowas unterstützten, aber ich halte wirklich wenig davon, java features zu spendieren, die bereits umsetzbar sind.



Welche Konstrukte sollen das sein? Bei Java fallen mir nur Interfaces und anonyme innere Klassen ein. Die sind aber sehr schwerfällig und kein vollwertiger Ersatz.


----------



## Janus (28. Jun 2008)

```
Action createAction( Object someVar );
Result doSomethingUseful( Environment e, Action action );
```
bildet closures so ziemlich ab. für das, was die meisten mit closures anfangen wollen, bietet das command pattern die nötige funktionalität. braucht man mehr, kann man das ganze noch mit diversen factories kombinieren.

wenn die einhellige meinung ist, dass mit dem einzug von closures auch lamba ausdrücke unterstützt werden müssen: das sind zwei unterschiedliche konzepte. denn lambda ausdrücke kann man in java wirklich nur schwerlich umsetzen. bleibt allerdings die frage, ob man die wirklich braucht.


----------



## tfa (30. Jun 2008)

Janus hat gesagt.:
			
		

> [...]bildet closures so ziemlich ab.


Bestimmt nicht.


			
				Janus hat gesagt.:
			
		

> für das, was die meisten mit closures anfangen wollen, bietet das command pattern die nötige funktionalität.


Wenn du damit nicht mehr anfangen willst, brauchst du wirklich keine Closures. Ein Closure ist ein "Funktionsabschluss" mit Zugriff auf freie Variablen in dem er definiert bzw. verwendet wird. Und das geht eben mit Java nicht.
In anderen Sprachen (funktionalen und multiparadigmen-Sprachen) habe ich Closures schätzen gelernt. Ob sie was in Java bringen, kann man schlecht voraussagen -- sicherlich wären sie sinnvoller als Mehrfachvererbung. Bis man sie wirklich produktiv einsetzen kann, werden eh noch etliche Jahre vergehen.


----------



## Janus (30. Jun 2008)

total tolle closures

```
public class Closure
{
	private Runnable inc;
	private Runnable pc;
	
	public Closure()
	{
		final int[] counter = { 0 };
		this.inc = new Runnable()
		{
			public void run()
			{
				counter[ 0 ] += 1;
			}
		};
		this.pc = new Runnable()
		{
			public void run()
			{
				System.out.println( counter[ 0 ] );
			}
		};
	}
	
	public static void main(String[] args)
	{
		Closure c = new Closure();
		c.inc.run();
		c.inc.run();
		c.pc.run();
		c.inc.run();
		c.pc.run();
	}
}
```

natürlich erlaubt java keine lambda ausdrücke oder funktionspointer. wenn man das auch noch als bestandteil von closures sieht, dann hat man halt pech gehabt


----------



## tfa (1. Jul 2008)

Janus hat gesagt.:
			
		

> total tolle closures
> [...]


Irre! Deine Ansprüche möcht ich haben...


----------



## foobar (1. Jul 2008)

@Janus Was hat das mit Closures zu tun bzw. wo soll hier der Mehrwert sein?


----------



## Janus_ (1. Jul 2008)

liefer mir mal ein beispiel, was du mit closures so tolles anstellst, ohne dabei irgendwelche anderen sprachmittel auszunutzen. ein reines closure sozusagen.


----------



## foobar (1. Jul 2008)

Hab doch schon ein Beispiel geliefert. Überall dort wo man jetzt innere Klassen mit wenig Code in der invoke Methode verwendet. Was meinst du mit reiner Closure? Man kann sehr gut ohne Closure auskommen, aber mit Closures kann man sich viel Tipparbeit sparen und genau da sehe ich den Vorteil.


----------



## SlaterB (1. Jul 2008)

meinst du
> myButton.addSelectionListener({ => doSomething(); });
?

dass sowas jemals geht ist ja sehr schwer vorzustellen,
was wäre denn da die Regel?:
"wenn eine Operation einen Interface-Parameter verlangt und dieses Interface aus genau einer Operation besteht,
dann ignoriere dessen Parameter (z.B. SelectionEvent, oder soll man darauf immer noch zugreifen können?) 
und erlaube { => Code }
wobei 'Code' dann in eine neu angelegte anonyme innere Klasse des fraglichen Codes kopiert wird"


ist das eine realistische Programmiersprache?
gut, die Frage kann man sich zu anonymen inneren Klassen an sich genauso stellen, aber da gibts noch ein wenig System, finde ich,

zumal du in deinem Beispiel sogar vom Ersatz eines Adapters sprichst,
was impliziert, dass das eigentliche Interface mehrere Operationen hat,
welche davon soll dann gefüllt werden oder alle?



ich hab gerade bisschen versucht, nach Closures im Internet zu suchen
und nicht wirklich alles überblickt, aber diese merkwürdige Abkürzung ganz gewiss nicht gefunden,
eher was zu Variablen, deren Wert sich gemerkt wird


----------



## schalentier (1. Jul 2008)

Guggst du hier:

http://groovy.codehaus.org/Closures

Da sind ne Menge Beispiele. Durch Closures (in Groovy) ergeben sich noch eine Reihe weiterer interessanter Konzepte:

http://groovy.codehaus.org/Builders


Ob das allerdings was in Java zu suchen hat, da bin ich mir nicht sicher. Java sollte so einfach wie moeglich bleiben, deswegen wuensch ich mir fuer die naechste Version das Abschaffen von Generics :-D

Wer mehr Sprachfeatures braucht, kann auch Groovy nehmen, da gibts das alles schon...


----------



## SlaterB (1. Jul 2008)

also eine reine Definition eines Code-Blocks ohne typisierte Parameter oder Interfaces

und der Button könnten dann zusätzlich zum normalen addSelectionListener(SelectionListener);
noch das unspezifizierte addSelectionListener(AnyClosure); anbieten

hmm, damit könnte ich leben, ist erlaubt


----------



## schalentier (1. Jul 2008)

Listener sind nur ein winziger Bruchteil dessen, was mit Closures machbar ist. Viel interessanter ist mMn, dass man damit endlich Quellcode von doppelten Code wie er in Schleifen vorkommt befreien kann.

Anstatt:

```
for( int i=0; i<10; i++ ) { // do it }
```

Koennte man das so schreiben:

```
(0..9).each( {// do it } )
```

Aber wie gesagt, hat in Java irgendwie nix zu suchen, finde ich. Klar kann man jetzt coole Sachen von Groovy auch in Java einbauen, aber dann hat man am Ende ein halbes Groovy... wozu?


----------



## Illuvatar (1. Jul 2008)

schalentier hat gesagt.:
			
		

> Koennte man das so schreiben:
> 
> ```
> (0..9).each( {// do it } )
> ```



Oder einfacher 

```
10.times { /* whatever */ }
```


----------



## Saxony (1. Jul 2008)

Aha,

und wie komme ich an den aktuellen Index in so einem Fall?

Wie bei Perl vielleicht?


```
(0..9).each( { sysout($_) } )
```

Bei der Variante:


```
10.times { /* whatever */ }
```

wie ist da der aktuelle Index? Geht das von 0-9, oder 10-19 oder wie? Oder soll das nur etwas 10 mal ausführen ohne einen Index zu erzeugen?

bye Saxony


----------



## foobar (1. Jul 2008)

Also ich finde Closures machen das Leben leichter genauso wie Generics, Annotations und Wrapper. Hier gibts ne ganz nette Überischt was mit Closures alles möglich werden könnte:
http://www.tutego.com/blog/javainsel/2008/02/java-closures-inselupdate-fr-java-7.html

@Slaterb man kann eine Closure sehr wohl parametrisieren. Ich habe das Beispiel bewusst simpel gehalten.


----------



## tfa (1. Jul 2008)

Saxony hat gesagt.:
			
		

> ```
> 10.times { /* whatever */ }
> ```
> 
> wie ist da der aktuelle Index? Geht das von 0-9, oder 10-19 oder wie? Oder soll das nur etwas 10 mal ausführen ohne einen Index zu erzeugen?



Beispiel in Ruby-Code:

```
10.times { |index| print index }
-->0123456789
```
Noch ein interessanter Link: http://www.javaworld.com/javaworld/jw-06-2008/jw-06-closures.html


----------



## Illuvatar (1. Jul 2008)

@Saxony:
In Groovy entweder mit Deklaration

```
10.times { index ->
   println (index)
}
```
oder ansonsten über die automatisch erstellte Variable "it"

```
10.times {
   println (it)
}
```
Hier geht der Index von 0 bis 9, bei der Variante mit der Range kann man das natürlich selbst festlegen

```
(23..42).each {
   println (it)
}
```

In Java würde das allerdings alles nochmal anders aussehen. Methoden auf ints anwenden und so ist ja nicht 
Bin auch nicht ganz sicher ob Java das braucht. Es ist sehr komfortabel, aber nochmal eine Menge Syntax. Und es gibt sicher einige Fälle die dann nicht ganz intuitiv sind, bei Vermischung von inneren Klassen und Closures und so (was bedeutet this? wie greife ich auf welches Objekt zu?) - mir fällt grad kein richtig konkretes Beispiel ein, hab mich noch nicht genauer damit beschäftigt, könnte es mir aber gut vorstellen dass es solche Probleme gibt.


----------



## foobar (1. Jul 2008)

Wir sollten noch nen 2ten Thread erstellen mit dem Titel "Java 8 Wunschliste". Ich mache mal den Anfang:
- Lamda-Kalkül
- Ranges
- Defaultvariablen wie $_ @_ $! etc.

Spätestens mit Java 9 werden dann die Scriptsprachen der VM wie Groovy oder JRuby obsolet, weil Java von Haus aus schon wesentlich mehr leistet ;-)


----------



## Saxony (1. Jul 2008)

foobar hat gesagt.:
			
		

> Spätestens mit Java 9 werden dann die Scriptsprachen der VM wie Groovy oder JRuby obsolet, weil Java von Haus aus schon wesentlich mehr leistet ;-)



In Java 10 will ich nur noch meine Anwendungsfälle als Fließtext eintippen müssen!

Nach dem Motto:

Mach ein Programm mit Oberfläche, womit ich einfach meine Laufwerke und Dateien anzeigen lassen kann!

compile drücken - und schwupps purzelt nen FileBrowser hinten raus. 

Der Compiler liest es dann so:

"Mach ein Programm" -> lege eine Klasse mit main() an
"mit Oberfläche" -> verwende grafische Koponenten zur Anzeige auf dem Bildschirm
"womit ich einfach" -> keine verschachtelten Menüs, Verwendung von ToolBar - halt einfach nutzerfreundlich
"meine" -> bleibe auf localhost, gib aber die Möglichkeit zur Anzeige eingebundener (meine) Netzlaufwerke
"Laufwerke" -> scannen, lesen und anzeige der HDDs und Partitionen
"und Dateien" -> auslesen, anzeige der Dateien auf den HDDs und Partionen
"anzeigen lassen kann" -> nicht als always-on-top, full-screen, ohne close button in den Auto-Start 
"!" -> und zwar JETZT!

bye Saxony


----------



## Titanpharao (6. Jul 2008)

Ich würde mit mehr Funktionen zu Threads wünschen. Beispiel .destroy() oder .close() (hieß das so?) Also um einen Thread einfach zu beenden. Aber halt sicher


----------



## didjitalist (6. Jul 2008)

Titanpharao hat gesagt.:
			
		

> Ich würde mit mehr Funktionen zu Threads wünschen. Beispiel .destroy() oder .close() (hieß das so?) Also um einen Thread einfach zu beenden. Aber halt sicher



Atomare Blöcke :toll: Ich fänds exzellent, wenn man in Java atomare Blöcke definieren könnte, die garantiert immer abgeschlossen werden, solange die VM noch rennt.


----------



## Ark (6. Jul 2008)

(Vorangegangene Beiträge habe ich nur überflogen.)

Ich bin generell Sprachfeatures abgeneigt, die hohe Komplexitäten hinter leicht aussehenden Schreibweisen "verbergen". Schon das Autoboxing halte ich für eine nicht so tolle Idee, weil hier z.B. verschleiert wird, dass in Wirklichkeit mit Objekten und eben nicht mit relativ "leichten" primitiven Datentypen hantiert wird. Auch mit der foreach-Schleife konnte ich mich (bisher) nicht wirklich anfreunden. Von Operatorüberladung halte ich entsprechend wenig, weil auch hier eine komplexe Operation wie die Multiplikation zweier BigDecimals im Code als eine scheinbar leichte Operation dargestellt werden könnte.

Dass die Stringverkettung eine Operatorüberladung erfahren hat, kann ich insofern billigen, als dass auch Stringliterale die Sprache schmücken und beides zusammen vermutlich hauptsächlich zum Erzeugen von konstanten (Exception-)Nachrichten oder Debug-Informationen genutzt wird. (Ansonsten sollte man ja StringBuilder oder StringBuffer benutzen.)

Switch-Case über Strings lehne ich auch ab, da ganz andere Prinzipien (im Gegensatz zu primitiven Datentypen) zum Tragen kämen.

Nun zu meiner positiven Wunschliste:

- Collections-Framework auch für primitive Datentypen (z.B. IntHashSet)
- Angabe eines Typs für null, wenn sonst Mehrdeutigkeiten auftreten könnten, Beispiel:

```
JDialog blubb = new JDialog((Window)null, "Auch ohne Dummy eindeutig!");
```
- Bereichsangaben für Switches:

```
case 'a'..'m', 'o'..'z': System.out.println("Ähnelt einem in-Operator");
```
- mehrere Sichtbarkeitsmodifizierer für Eigenschaften, um mehr Leserechte einzuräumen (dies würde langatmige Methodenaufrufe und langweilige Getter im Quelltext vermeiden):

```
public private int kannÖffentlichGelesenWerden;
```
- Zwei neue Klassen java.math.Complex und java.math.Rational, um eben mit solchen Zahlen umgehen zu können.
- Vier neue Methoden in der Klasse Math:

```
public long pow(long a, long b)
public long factorial(int n)
public long gcd(long a, long b)
public long lcm(long a, long b)
```
- Swing sollte an vielen Stellen (z.B. JLabel) CharSequences anstatt nur String akzeptieren können, denn ich sehe nicht ein, warum ich vielleicht nur für eine kleine Anzeige jedes Mal einen neuen String erzeugen soll, sobald sich ein Wert (z.B. eine Cursorposition, die angezeigt wird) ändert.

So viel bis jetzt von meiner Seite.

Ark


----------



## Guest (6. Jul 2008)

- ein integrierter Generator für einen VM-Launcher. (für alle unterstützten Plattformen)
- Etwas ähnliches wie das with-Statement in C#

```
with(Connection con = getConnection())
{
   ...
}
// an dieser Stelle ist alles freigegeben
```
- weniger Checked-Exceptions in der API.
- Abstraktion der GUI-API. Sowas wie XAML.


----------



## Guest (6. Jul 2008)

Es sollte "using", nicht "with" heissen.


----------



## didjitalist (6. Jul 2008)

Die with-Syntax kenne ich aus VB und ich hab sie dort schon nicht gemocht 

Häufig wird Code einfach deshalb unübersichtlich, weil die minimal qualifizierenden Bezeichner gewählt werden. Dann am Besten noch ein paar static imports einstreuen und schon muss man in jeder zweiten Zeile nachgucken, wo jetzt schon wieder eine Konstante oder Methode herkommt.

Ich bin sehr dafür, Java um Dinge zu erweitern, die Standardlösungen fördern und Code sicherer machen können. Aber gerade solch Kontextgefrickel wie 'with/using' oder - noch schlimmer - Templates soll bitte draussen belieben.


----------



## Gast (6. Jul 2008)

Die Startzeit der Java Applets auf die von Flash zu drücken.
Grund: Java ist 100 mal mächtiger als Flash. Nur kann man Java momentan nicht auf diesem Gebiet einsetzen, zumindest nicht wenn man sich nicht den letzten Besucher vergraulen will.


----------



## ps (6. Jul 2008)

an dieser Stelle setzt doch Java 6 Update 10 an - ich denke damit wird die Startgeschwindigkeit von JavaFX erheblich gedrückt.. dazu eine schöne IDE.. das wär was 

Auf meiner Wunschliste von der Sprache Java an sich steht zB. Arrays direkt als Parameter übergeben zu können, zB:
Object o = methode({"eins","zwei","drei"}, parameter2);

oder geht das schon irgendwie? ^^


----------



## tfa (6. Jul 2008)

ps hat gesagt.:
			
		

> Auf meiner Wunschliste von der Sprache Java an sich steht zB. Arrays direkt als Parameter übergeben zu können, zB:
> Object o = methode({"eins","zwei","drei"}, parameter2);
> 
> oder geht das schon irgendwie?




```
Object o = methode(new String[]{"eins","zwei","drei"}, parameter2);
```
 :?:


----------



## Wildcard (6. Jul 2008)

Ausserdem gibt's varargs


----------



## didjitalist (6. Jul 2008)

Die Kombination von varargs und Collections find ich ganz nett dafür.

```
void foo( List<?> arg0, List<?> arg1 )
{
  // ...
}

// ...
foo( Arrays.asList( "Foo", "Bar", "Baz" ), Arrays.asList( 23, 42 ) );
```


----------



## SlaterB (6. Jul 2008)

Ark hat gesagt.:
			
		

> - Angabe eines Typs für null, wenn sonst Mehrdeutigkeiten auftreten könnten, Beispiel:
> 
> ```
> JDialog blubb = new JDialog((Window)null, "Auch ohne Dummy eindeutig!");
> ```


gibts genau in dieser Form schon


----------



## DEvent (9. Jul 2008)

Anonymous hat gesagt.:
			
		

> - Etwas ähnliches wie das with-Statement in C#
> 
> ```
> with(Connection con = getConnection())
> ...



Was spricht gegen

```
function()
{
    {
        Connection con = getConnection();
        // ...
    }
    // hier ist con nicht mehr gueltig, kann vom GC einkassiert werden
}
```



			
				Ark hat gesagt.:
			
		

> - Collections-Framework auch für primitive Datentypen (z.B. IntHashSet)


Gibts doch schon: http://pcj.sourceforge.net/



Ich haette gerne fuer Java 7 die Abschaffung der checked-Exceptions.


----------



## tfa (9. Jul 2008)

DEvent hat gesagt.:
			
		

> Was spricht gegen
> 
> ```
> function()
> ...


con kann zwar einkassiert werden, aber niemand weiß wann. Es gibt
keine Destruktoren in Java. In einem C#-with-Block würden die Ressourcen
nach verlassen wieder freigegeben werden (die Klasse muss IDisposable implementieren).
Momentan kann man sich in Java nur so behelfen:


```
Connection con=null;
try {
   con = getConnection();
}
finally {
   if (con!=null) con.dispose(); 
}
```


----------



## byte (9. Jul 2008)

DEvent hat gesagt.:
			
		

> Was spricht gegen
> 
> ```
> function()
> ...


Dagegen spricht, dass der GC zwar Objekte aus dem Heap entfernen kann, aber nicht selbsständig Resourcen freigibt. Eine JDBC Connection muss explizit mit close() geschlossen werden. Ähnliches trifft auf Streams, Reader oder Writer zu.


----------



## DEvent (9. Jul 2008)

Ok habe ich wohl uebersehen 

Mir faellt da grade noch was ein:

Eine bessere try-catch-finally Syntax. Sie sollte kuerzer sein und nicht so viele () oder {} beinhalten.
Eine Verknuepfung der catches waehre nicht schlecht:


```
try 
{
    // ...
}
catch (IOException, SQLException e)
{
    e.printStack();
}
```


----------



## tfa (9. Jul 2008)

Es gibt einen Vorschlag von Josh Bloch, "do" dafür zu verwenden. "try" ist ihm aber auch eine Überlegung wert, da man dann solche Blöcke auch einfach mit catch kombinieren könnte.


----------



## byte (9. Jul 2008)

DEvent hat gesagt.:
			
		

> Eine Verknuepfung der catches waehre nicht schlecht:
> 
> 
> ```
> ...


Wie soll das denn funktionieren in einer statisch getypten Sprache? ???:L

Du kannst aber den gleichen Effekt schon heute erreichen, indem Du den Supertyp fängst.


----------



## tfa (9. Jul 2008)

Warum sollte das nicht gehen? Die Exceptions müssen ja nichts miteinander zu tun haben, dann wäre der Supertyp java.lang.Exception und man fängt alle möglichen Exceptions.


----------



## byte (9. Jul 2008)

Im Catch-Block wäre der genaue Typ von e nicht spezifiziert.


----------



## Gelöschtes Mitglied 5909 (9. Jul 2008)

byto hat gesagt.:
			
		

> DEvent hat gesagt.:
> 
> 
> 
> ...



und was is mit runtimeexceptions? die zu catchen mit catch Exception is oft nicht so gut 



			
				byto hat gesagt.:
			
		

> Im Catch-Block wäre der genaue Typ von e nicht spezifiziert.



wie wärs denn mit sowas?

catch (IOException ioe, SQLException sqle)


----------



## tfa (9. Jul 2008)

Der Typ von e wäre dann von einer gemeinsamen Oberklasse. Die Hauptsache ist, dass nur die konkret angegebenen Exceptions gefangen werden. 
Es gibt jedenfalls Vorschläge für ein "improved catch":
http://tech.puredanger.com/java7#catch
http://www.briangoetz.com/blog/?p=43


----------



## DEvent (9. Jul 2008)

tfa hat gesagt.:
			
		

> Der Typ von e wäre dann von einer gemeinsamen Oberklasse. Die Hauptsache ist, dass nur die konkret angegebenen Exceptions gefangen werden.
> Es gibt jedenfalls Vorschläge für ein "improved catch":
> 
> http://www.briangoetz.com/blog/?p=43



Genau das Problem in dem Blog habe ich auch jeden Tag. Wenn man z.B. mit Reflection arbeitet, dann kann schnell passieren das man 5 oder mehr Exceptions fangen muss.

try { irgend ein 2-Zeiler }
catch ... 
{
}
catch ... 
{
}
catch ... 
{
}
catch ... 
{
}
catch ... 
{
}
catch ... 
{
}
usw.

Meistens erspare ich mir die Arbeit und catche einfach Exception.

Mich nerven checked-exceptions aber auch langsam. Wenn eine Exception fliegt und man sie nicht richtig faengt, dann sollte das Programm sich einfach beenden. Mit checked-Exception aber sehe ich oft:

```
try{ /* irgendwas */ }
catch { IOException e }
{
    e.printStack();
}
```
So mehr nicht. Dann gibt es auf der Console eine Fehlermeldung, aber das Programm laeuft munter weiter, weil der Programmierer zu faul war eine richtige Exception-Behandlung zu schreiben. Wenn es keine checked Exceptions gaebe, dann wuerde der faule Programmierer IOException ueberhaupt nicht fangen und das Programm wuerde sich beenden.

Zum anderen ist das Konzept nicht sauber in Java. Was ist wenn ich einen Iterator habe, dessen next() Methode irgendwas aufrufen muss, dass eine checked-Exception wirft?

```
FooIterator implements Iterator<Foo>
{
    public Foo next()
    {
        try { /* irgendwas */ }
        catch ( SQLException e )
        {
            // was mache ich nun damit?
            // am sinnvollsten waehre throw new RunntimeException(e);
        }
    }
}
```
Nun muss ich die SQLException in eine unchecked-Exception verpaken. Wozu dann aber checked-Exception ueberhaupt?


----------



## SlaterB (9. Jul 2008)

> Nun muss ich die SQLException in eine unchecked-Exception verpaken. Wozu dann aber checked-Exception ueberhaupt?

aha

weil etwas in einer bestimmten Situation nicht geht, soll es abgeschafft werden?

mit einem Iterator kann man kein int von einer int-Sammlungs-Klasse zurückgeben
-> int abschaffen?


dieses Argument passt nicht, andere natürlich schon


----------



## tfa (9. Jul 2008)

DEvent hat gesagt.:
			
		

> Wozu dann aber checked-Exception ueberhaupt?


Es war halt ein Experiment, ein neues Konzept, das nicht besonders gut funktioniert hat. Jetzt werden wir es nicht mehr los. Hinterher ist man immer schlauer.


----------



## didjitalist (9. Jul 2008)

Ich finde das Konzept der checked exceptions gut, nur ist die Umsetzung in den meisten Fällen schlecht. Warum z.B. schmeissen ausnahmslos alle Datenbank APIs checked exceptions, wenn irgendwas mit der Verbindung nicht stimmt? Solche exceptions treten im normalen Programmablauf so gut wie nie auf. Ausnahmen, die aller Wahrscheinlichkeit nach normalerweise nicht auftreten, sollten auch keine checked exceptions schmeissen.

Erst sobald eine Methode eine sehr hohe Wahrscheinlichkeit besitzt, eine exception zu schmeissen, sollte dies eine checked exception sein. Als Beispiel können da Methoden wie Integer#parseInt herhalten.


----------



## AlArenal (9. Jul 2008)

@didjitalist:

Ich glaube dir ist die (gar nichtmal so tiefe) Bedeutung des Wortes "Ausnahme" entgangen...


----------



## didjitalist (9. Jul 2008)

Es geht hier nicht um die Begrifflichkeit "Ausnahme". Es geht um die Unterscheidung zwischen checked und unchecked exceptions.

Ich sehe wenig Sinn im inflationären Gebrauch von checked exceptions. Das verleitet lediglich dazu, genau die exceptions, die fatal sein können, geflissentlich zu ignorieren. Warum denn setzt sogar eine recht gebräuchliche IDE wie eclipse als Standardpattern für automatisch generierten Code das unglaublich sinnfreie "e.printStackTrace()" ein? Ich hab schon verdammt viel Code gesehen, der checked exceptions immer weiter und weiterreicht, bis sie irgendwann irgendwo im GUI verschluckt werden, weil irgendwer "mal eben" was umsetzen und sich zu dem Zeitpunkt keine Gedanken über sinnvolle Fehlerbehandlung mehr machen wollte.


----------



## AlArenal (9. Jul 2008)

Gegen verhunzten Code helfen keine Featuritis, denn schlechten Stil kann man nicht "Par Ordre De Mufti" unterbinden. Vorhandene Möglichkeiten sinnvoll einzusetzen ist numal Aufgabe des Programmierers und der kann sich nciht darauf berufen, dass ihn die Sprache verleitet hätte, obwohl er es auch hätte besser machen können.

Nachträglich Features entfernen ist erfahrungsgemäß nichts, was man von Sun zu erwarten hat.


----------



## byte (9. Jul 2008)

Das Konzept ist imo ok, aber es fehlt eine Möglichkeit, ohne Code Bloat alle checked Exceptions zu fangen.


----------



## SlaterB (9. Jul 2008)

> Warum denn setzt sogar eine recht gebräuchliche IDE wie eclipse als Standardpattern für automatisch generierten Code das unglaublich sinnfreie "e.printStackTrace()" ein?

auch hier wieder mahnende Gegenworte:
was anderes geht gar nicht, das ist schon eine sehr löbliche Sache,

wenn man von Eclipse Operationen mit Rückgaberwer generieren lässt,
dann wird da 'return null' reingeschrieben, 
auch wenig sinnvoll aber Eclipse kann sich nun wirklich keinen intelligenten Code ausdenken

wenn Eclipse standarmäßig
throw new RuntimeException(e);
schreiben würde, ja dann wäre die Einstellung der Eclipseprogrammierer deutlich  :bae:


----------



## tfa (9. Jul 2008)

byto hat gesagt.:
			
		

> Das Konzept ist imo ok


Wenn  es nichtmal die Java-Schöpfer vernünftig verwenden (siehe viele checked Exceptions bei Reflection, SQLException), was kann man von normalen Entwicklern erwarten?
Checked Exceptions könnten vielleicht bei der Anwendungsentwicklung sinnvoll sein (wenn man wirklich weiß, dass eine Ausnahmesituation behandelt werden kann und muss), aber nicht in allgemein verwendbaren APIs oder Frameworks.


----------



## SlaterB (10. Jul 2008)

andererseits erziehen Checked Exceptions zur Kapselung,

ich finde es immer ganz schrecklich, wenn Framework-Operationen im Programm verteilt sind,
z.B. Hibernate query.list() oder transaction.commit(),

da das ein Einzeiler ist, steht das in meinem Projekt bei jeder von hunderten DB-Operationen einzeln,
und wenn ich nun die Querys zählen, loggen, gar auf Exceptions reagieren will?

wäre diese wichtige Operation ein 10 Zeilen-Code mit try/ catch,
dann wäre sie hoffentlich schon viel eher in eine Wrapper-Operation gewandert die von hunderten Stellen im Programm aufgerufen wird,

das ist kein direkter Zusammenhang mit Checked Exceptions, schließlich gibts auch genug Operationen ganz ohne Exceptions, die man evtl. wrappen möchte,

aber wenn eine Operation eines Framework Exceptions wirft,
dann braucht man die in einem strukturierten Programm nur genau einmal abzufangen,
dieser Aufwand ist nicht allzu hoch


----------



## byte (10. Jul 2008)

Das hat nun aber wirklich nichts mit dem Exception-Konzept zu tun sondern vielmehr mehr mit dem Design Deiner Anwendung. Oben aufgezählte Hibernate-Methoden werfen alle eine HibernateException, aber die ist halt Unchecked. Die kannst Du genauso fangen wie eine checked Exception, musst es aber nicht. 
Du musst hier überlegen, wie Du Deine Persistenzschicht strukturierst - ob checked oder unchecked Exceptions fliegen ist dabei doch egal.

Warum sollte man ein _try { query.list } catch(Exception e) { /* Exception Handling */ }_ eher wegkapseln? Jemand, der weiss was er tut, wird sich eh eine Persistenzschicht mit DAOs hochziehen. Und wer nicht weiss was er tut, der wird auch hier nichts vernünftig kapseln.


----------



## SlaterB (10. Jul 2008)

> Warum sollte man ein try { query.list } catch(Exception e) { /* Exception Handling */ } eher wegkapseln? 

aufgrund der Code-Länge, wie gesagt,
wenn du das nicht so siehst ist das ja ok, aber brauchst nicht nochmal warum fragen


----------



## byte (10. Jul 2008)

Aha, na dann. :roll:


----------



## Generic1 (10. Jul 2008)

Ich hab jetzt auch einen Wunsch,
Das Drucken in Java sollte so schnell als möglich überarbeitet werden, da keine Modifikationen an den PrintFrames (Seite einrichten und drucken) möglich sind, das aber manchmal sinn macht,

lg


----------



## AlArenal (10. Jul 2008)

http://www.softframeworks.com/products/products.php


----------



## DEvent (11. Jul 2008)

SlaterB hat gesagt.:
			
		

> > Warum sollte man ein try { query.list } catch(Exception e) { /* Exception Handling */ } eher wegkapseln?
> 
> aufgrund der Code-Länge, wie gesagt,
> wenn du das nicht so siehst ist das ja ok, aber brauchst nicht nochmal warum fragen



Ich wuerde eher sagen wegen vermeidung von Code-Duplication. Im uebrigem neigen checked-Exceptions sowieso zu code-duplication.

Was spricht eigentlich _fuer_ checked-Exceptions? Doch nur das man sie fangen muss. Aber was der Programmierer damit macht, steht nirgens. Wenn Eclipse nicht immer ein // TODO hinzufuegen wuerde, dann wuerden die gefangenen checked Exceptions noch schneller in Vergessenheit geraten.

Frueher habe ich mir keine Gedanken gemacht um checked/unchecked Excepions, aber je laenger ich darueber nachdenke desto mehr komme ich zu dem Schluss, dass sie eine ganz schlechte Idee sind. In der Theorie hoert sich das ganz gut an: Wie zwingen die Programmierer mit checked Exceptions zur richtiger Fehler-Behandlung. In der Praxis zeigt sich aber die wahre Natur eines jeden Programmierer: Die Faulheit.

Ohne checked Exceptions ist die Faulheit kein Problem: Wenn der Programmierer zu faul zur richtigen Fehler-Behandlung war, dann beendet sich das Programm wenn eine Exception fliegt. Mit checked Exeptions laeuft das Programm weiter in einem undefinierten Zustand.


----------



## SlaterB (11. Jul 2008)

> Ich wuerde eher sagen wegen vermeidung von Code-Duplication. Im uebrigem neigen checked-Exceptions sowieso zu code-duplication.

klar Code-Duplication, wenns nicht der gleiche Code wäre, dann könnte man ihn ja nicht in eine Operation zusammenfassen,
Code-Duplication == Code-Länge 

-----

ein guter Vergleich zwischen Checked und Unchecked ist auch ein Interface vs Adapter/ Basisklasse,
bei ersterem fängt man ganz bei null an und muss alles behandeln,
bei zweiterem verläßt man sich auf den Default, muss eigentlich nix machen sondern überschreibt nur (fängt nur ab), was aktuell nötig ist

das passt auch zum Kapselungs-Konzept, 
wenns keinen WindowAdapter gäbe, dann müsste man ihn sich wirklich selber schreiben bei derart vielen Operationen die man oft nicht braucht


----------

