Eure Wunschliste für Java 7?

[jollyroger]

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]

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]

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]

- 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]

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.

A simple presentation that explains continuations clearly can be downloaded from here.

If wonder about how to debug continuations, look at this presentation.

Zitat:

- 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.

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]

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]

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]

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]

und ein paar mehr Swing Widgets.

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

bye Saxony

 

[maki]

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]

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]

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

 

[tfa]

-> 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]

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]

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]

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]

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]

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

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

 

[maki]

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

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

Ja, ging schon immer, alternativ dazu

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

 

[Saxony]

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]

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]

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]

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]

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]

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

: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]

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]

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]

@ 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]

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]

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]

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]

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]

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]

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]

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]

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]

genau mit der tradition will ich ja brechen

 

[foobar]

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]

@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]

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

 

[foobar]

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]

- 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]

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]

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]

- 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]

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]

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]

---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]

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

 

[ARadauer]

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