Eure Wunschliste für Java 7?

[foobar]

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

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

 

[byte]

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

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]

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

 

[Janus]

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]

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]

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]

[...]bildet closures so ziemlich ab.

Bestimmt nicht.

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]

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]

total tolle closures
[...]

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

 

[foobar]

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

 

[Janus_]

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

 

[foobar]

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]

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]

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]

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]

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]

Koennte man das so schreiben:

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

Oder einfacher

10.times { /* whatever */ }

 

[Saxony]

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]

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]

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]

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

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]

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]

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]

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]

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

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

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

 

[didjitalist]

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]

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]

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]

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]

Ausserdem gibt's varargs

 

[didjitalist]

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]

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

- Etwas ähnliches wie das with-Statement in C#

with(Connection con = getConnection())
{
   ...
}
// an dieser Stelle ist alles freigegeben

Was spricht gegen

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

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

Was spricht gegen

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

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]

Was spricht gegen

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

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]

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]

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]

Eine Verknuepfung der catches waehre nicht schlecht:

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

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]

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]

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

 

[Gelöschtes Mitglied 5909]

Eine Verknuepfung der catches waehre nicht schlecht:

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

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.

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

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

wie wärs denn mit sowas?

catch (IOException ioe, SQLException sqle)

 

[tfa]

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]

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]

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

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.