Umsteigen nach C++ oder lieber c#?
-
Das ist die Meinung eines Anfängers.
Ich mein man muss doch nur wissen, wie ein Algorithmus funktioniert. Das implementieren ist dann doch eher nebensache.
Beispiel Quicksort: Wenn man eine leere Liste sortieren soll, ist das Ergebnis eine leere Liste. Sonst: Man nehme ein Element, rufe sich selbst mit den Elemente auf, die kleiner als dieses Element sind und nochmals mit den Elementen, die größer oder gleich diesem einen Element sind. Dann hängt man diese beiden Listen aneinander und alles ist sortiert.Das könnte man doch jetzt mal eben einkloppen:
template<typename T, typename P> vector<T> filter (vector<T> const & source, P pred) { vector<T> tmp; for (vector<T>::const_iterator it=source.begin(); it!=source.end(); ++it) if (pred(*t)) tmp.push_back (*it); } vector<T> quicksort (vector<T> list) { if (list.empty()) return vector<T>(); else { vector<T> result; result.insert (result.end(), quicksort (filter<T>(bind2nd (less<T>(), list[0]))); result.insert (result.end(), quicksort (filter<T>(bind2nd (greater_equal<T>(), list[0]))); return result; } }
(Ungetestet, garantiert Vertipper drin).
Gut man sieht, das C++ nicht die Optimale Sprache für solche Algorithmen ist. Aber es gibt natürlich Sprachen, die für sowas geeignet sind:
quicksort [] = [] quicksort (x:xs) = quicksort [y | y <- xs, y < x] ++ [x] ++ quicksort [y | y <- xs, y >= x]
Dafür hast du dann in C++ die Möglichkeit das ganze noch wesentlich effizienter zu bauen.
Nebenbei: Wieso gibt's in C++ eigentlich keine ordentlichen Lsiten (aus funktionaler Sicht)?
-
Real schrieb:
In Java gibt man irgendeine Klasse und eine Variable ein und schon hat sich alles erledigt. Das ist zumindest für Anfänger nicht gut (zähle mich selbst darunter)!
Darum bin ich strikt dagegen, dass man Java als erste Sprache lehrt!
Klar, ich bin auch der Meinung dass man lieber mit ASM anfangen soll. Denn da weiss man noch was man macht. Da wird man nicht so verweichlicht wie bei Hochsprachen.
-
Für Datenbanken und RAD Design??
Was hält Dich denn davon ab, bei Delphi zu bleiben?!?!
P.S.: Sorry, aber habe mir nicht alle 5 Seiten angeschaut, gehe einfach mal davon aus, daß Du es noch nicht erwähnt hast...
-
Shade Of Mine schrieb:
Real schrieb:
In Java gibt man irgendeine Klasse und eine Variable ein und schon hat sich alles erledigt. Das ist zumindest für Anfänger nicht gut (zähle mich selbst darunter)!
Darum bin ich strikt dagegen, dass man Java als erste Sprache lehrt!
Klar, ich bin auch der Meinung dass man lieber mit ASM anfangen soll. Denn da weiss man noch was man macht. Da wird man nicht so verweichlicht wie bei Hochsprachen.
Dann bitte auch kein ASM! Auch er ist kein 1:1 !
Lieber HEX-Code per Zehnertastatur direkt auf nen Chip zu 'nem 8086 senden!
-
@Sgt. Nukem: Sehr komisch. Du verrennst dich da gerade ein wenig.
@Real: Ich verstehe deine Argumentation nicht. Du glaubst, weil die Sprache odere deren Standard-Bibliothek bereits einige Features biete, die dem Programmierer für ihn triviale Grundlagenarbeit abnimmt, ist Sie für Anfänger nicht zu gebrauchen?
Wenn diesen Anfänger interessiert, wie ein Sortieralgorithmus funktioniert, kann er sich damit beschäftigen, unabhängig davon, ob die Sprache bereits etwas Vorgefertigtes bietet. Ein etwas erfahrener Programmierer würde eine Sprache wohl kaum verwenden wollen, wenn er jeden Kleinkram erstmal selbst entwickeln müsste.Bei mir gilt grundsätzlich:
- Es interessant zu wissen, wie etwas prinzipiell funktioniert
- Ich muss wiessen, wie ich es Anwende
- Es ist mir total egal, wie die konkrete, mir vorliegende Implementierung aussieht
-
Hallo,
ich könnte meine Argumente nur noch wiedeholen und ihr würdet dann eure widerholen bis irgendwann keine Argumente gepostet werden, sondern nur noch Müll die keinem weiterhelfen (siehe Shade Of Mine u. Sgt. Nukem die die ganze Diskusssion nach unten ziehen, da sie meine These ohne Argumente lächerlich darstellen und endlos übertreiben).Liebe Grüße
Real
-
Real schrieb:
sondern nur noch Müll die keinem weiterhelfen (siehe Shade Of Mine u. Sgt. Nukem die die ganze Diskusssion nach unten ziehen, da sie meine These ohne Argumente lächerlich darstellen und endlos übertreiben).
Das ist eine gängige Methode Argumente zu entkräften.
Du sagst dass die Sprache keine Algorithmen und so weiter anbieten soll. Folglich schlage ich dir ASM vor, denn diese Sprache tut dir garnix schenken tun.
Du betrachtest dass aus sicht eines Anfängers, das ist natürlich total falsch. Keine Ahnung wie weit du schon bist - aber für Profis ist eine mächtige Sprache wie C++ oder Java recht wichtig. Weil ich eben nicht die Zeit habe QSort zum 750ten Mal zu implementieren.
Und für Anfänger ist eine Sprache wie Java ziemlich nett, weil man recht schnell Erfolge erzielen kann und dennoch halbwegs ordentlich etwas lernt. Bei VB lernt man zB wesentlich weniger, weil man fast nur die GUI zusammenklickt. In Java muss man da mehr tun.
Und warum ist es schlecht wenn die Sprache etwas anbietet? Du musst es ja nicht verwenden.
Man fängt ja am Anfang an die Sprache zu verstehen - klar dass man da keine komplizierten Funktionen einbauen sollte, sondern alles selber schreiben sollte. Aber es ist schwachsinn zu sagen, dass es ein Nachteil einer Sprache ist, wenn sie mehr anbietet als du brauchst.
-
Shade Of Mine schrieb:
Du betrachtest dass aus sicht eines Anfängers, das ist natürlich total falsch. Keine Ahnung wie weit du schon bist - aber für Profis ist eine mächtige Sprache wie C++ oder Java recht wichtig. Weil ich eben nicht die Zeit habe QSort zum 750ten Mal zu implementieren.
ACK!
Für einen Anfänger macht es durchaus Sinn, sich z. B. eigene Sortieralgorithmen zu schreiben, aber wenn Du unter Zeitdruck arbeitest, liebst Du ein Framework ala stl oder sdk.
Ich finde auch nicht, dass das SDK Kompliziert ist. Es ist halt strikt OO. Sicherlich braucht man eine gewisse Zeit um die gebräuchlichsten Klassen zu kennen, aber das ist bei jedem Framework so.
Grüssle
-
Shade Of Mine schrieb:
Du sagst dass die Sprache keine Algorithmen und so weiter anbieten soll. Folglich schlage ich dir ASM vor, denn diese Sprache tut dir garnix schenken tun.
So? Wo habe ich das gesagt?! Ich habe gesagt, dass ich strikt dagegen bin, dass man Java als erste Programmiersprache lehrt! Assembler von Anfang an, ist natürlich für den Anfänger auch zu schwierig. Lieber mit C anfangen und später zu C++ wechseln und dann vielleicht noch Java lernen.
Übrigens lernen wir nächstes Jahr Assembler.
Keine Ahnung wie weit du schon bist - aber für Profis ist eine mächtige Sprache wie C++ oder Java recht wichtig. Weil ich eben nicht die Zeit habe QSort zum 750ten Mal zu implementieren.
Der Anfänger schon und genau darum ging es hier.
Und für Anfänger ist eine Sprache wie Java ziemlich nett, weil man recht schnell Erfolge erzielen kann und dennoch halbwegs ordentlich etwas lernt. Bei VB lernt man zB wesentlich weniger, weil man fast nur die GUI zusammenklickt. In Java muss man da mehr tun.
Java ist eine sehr komplexe und überfüllte Sprache. Ich lerne gerade autodikatatisch (den Unterricht in der Schule kann man vergessen) aus einem über 800 seitigen Java-Buch. Super, es wird erklärt, dass einfache Datentypen wie int in einer Collection nicht unterstützt werden, darum muss man Integer nehmen. Warum, das weiss ich natürlich nicht, hab mich im Internet informiert und nichts logisch erklärbares gefunden warum das so ist und warum ausgerechnet einfache Datentypen wie int nicht unterstützt werden.
Ich würde gerne einen Überblick haben, was bei Java (als Anfänger) nicht sehr leicht ist.Und warum ist es schlecht wenn die Sprache etwas anbietet? Du musst es ja nicht verwenden.
Raucher beklagen sich über die so hohen Zigarettensteuer, aber wer zwingt sie zum Rauchen, was ausserdem dumm ist?!
Verstehst du was ich meine?!
Man fängt ja am Anfang an die Sprache zu verstehen - klar dass man da keine komplizierten Funktionen einbauen sollte, sondern alles selber schreiben sollte. Aber es ist schwachsinn zu sagen, dass es ein Nachteil einer Sprache ist, wenn sie mehr anbietet als du brauchst.
Für Fortgeschrittene und Profis ist es allemal spitze!
Liebe Grüße
Real
-
Real schrieb:
Java ist eine sehr komplexe und überfüllte Sprache. Ich lerne gerade autodikatatisch (den Unterricht in der Schule kann man vergessen) aus einem über 800 seitigen Java-Buch. Super, es wird erklärt, dass einfache Datentypen wie int in einer Collection nicht unterstützt werden, darum muss man Integer nehmen. Warum, das weiss ich natürlich nicht, hab mich im Internet informiert und nichts logisch erklärbares gefunden warum das so ist und warum ausgerechnet einfache Datentypen wie int nicht unterstützt werden.
1. Java ist in keinster Weise überfüllt und komplex. Im Gegenteil: Von den Sprachmitteln her ist Java deutlich weniger komplex als C++. Du willst darauf anspielen, dass die Standardbibliothek sehr groß ist, das hat aber nichts mit der Komplexität der Sprache zu tun. Klassen in der Standardbibliothek zu kennen ist so ähnlich wie Vokabeln in einer gesprochenen Sprache kennen: Wenn man in einer gesprochenen Sprache eine Vokabel nicht kennt, dann muss man sie halt umschreiben und wenn man in Java eine Klasse nicht kennt, dann muss man sie halt selbst beschreiben.
2. Die Collections in der Standardbibliothek von Java sind für Objekte geschrieben, das heißt, dass sie als Parameter in den verschiedenen Methoden Instanzen der Klasse Object oder einer hieraus abgeleiteten Klasse erwarten. In Java ist jede Kasse von der Klasse Object direkt oder indirekt abgeleitet, deshalb kann man die Instanzen von jeder Klasse in Collections speichern. Die primitiven Datentypen sind in Java aber keine Objekte. Sie sind nicht von Object abgeleitet. Somit kann man sie auch nicht direkt in Collections abspeichern.
Wenn man trotzdem primitive Datentypen in Collections abspeichern möchte, dann hat man zwei Möglichkeiten: Entweder man schreibt sich entsprechende Collections für den entsprechenden primitiven Datentyp selbst oder man verpackt die primitiven Datentypen in den sogenannten Wrapper-Typen. Die Wrapper-Typen haben jeweils intern den einen primtiven Dytentyp gespeichert und sind natürlich jeweils von Object abgeleitet. Weil sie von Object abgeleitet sind, kann man sie in die Collections aus der Standardbibliothek stecken.
-
Das wird sich mit Java 1.5 zum Glück (wenigstens scheinbar) ändern. Die schlechte Performance dieser Vorgehensweise bleibt.
Echt schade, da hat man echt eine Riesenchance verpasst. Es lebe C#! :pWird für Real aber auch zu komplex sein.
-
Real schrieb:
So? Wo habe ich das gesagt?! Ich habe gesagt, dass ich strikt dagegen bin, dass man Java als erste Programmiersprache lehrt! Assembler von Anfang an, ist natürlich für den Anfänger auch zu schwierig. Lieber mit C anfangen und später zu C++ wechseln und dann vielleicht noch Java lernen.
*lol*
Du weisst schon, dass C auch hin und wieder als Makro Assembler bezeichnet wird?
C als erste Sprache ist eine Katastrophe. Denn C ist eine Sprache für Profis - du hast alle Freiheiten, kannst machen was du willst, der Compiler meckert nicht viel.
Das ist natürlich schlecht, wenn du nicht weisst was du tust. Was bei Anfängern ja durchaus mal vorkommen kann.
C++ ist eine extrem komplexe Sprache. Am Anfang verwendet man C++ sowieso nicht anders als Java: denn man wird keine höheren Features einsetzen.
Allerdings bietet Java hier den Vorteil, dass es 'Fehlertoleranter' ist.
zB wenn du über die Grenzen eines Arrays schreibt wirft Java ne Exception, ein C++ Programm schmiert ab.Ist natürlich geil für einen Anfänger wenn die Programme einfach so abschmieren - da sind Exception natürlich besser.
Der Anfänger schon und genau darum ging es hier.
Nein, auch ein Anfänger hat diese 'Zeit' nicht. Er hat zwar die 'Zeit' aber es macht keinen Sinn.
Ich zB habe QSort noch nie implementiert. Ich denke aber trotzdem, dass ich weiss, wie es funktioniert.
Ich würde einem Anfänger lieber erstmal BubbleSort und dann vielleicht ein schnelleres, wie zB ShellSort oder so zu implementieren geben. Das reicht eigentlich. Man kann nicht alles selber implementieren - man muss nur verstehen.
Und wie schon öfters erwähnt: nur weil die Sprache etwas anbietet, muss man es ja nicht gleich verwenden. zB bietet C auch ein QSort.
Java ist eine sehr komplexe und überfüllte Sprache.
Überfüllt??
Gerade Java ist ne schlanke Sprache - C++ Programmierer sagen hier auch des öfteren 'verkrüppelt'. Da ist definitiv kein Bloat drinnen.Ich lerne gerade autodikatatisch (den Unterricht in der Schule kann man vergessen) aus einem über 800 seitigen Java-Buch.
Ah, du lernst gerade - aber kannst uns schon etwas über die Sprache erzählen was wir noch nicht wissen
Super, es wird erklärt, dass einfache Datentypen wie int in einer Collection nicht unterstützt werden, darum muss man Integer nehmen. Warum, das weiss ich natürlich nicht, hab mich im Internet informiert und nichts logisch erklärbares gefunden warum das so ist und warum ausgerechnet einfache Datentypen wie int nicht unterstützt werden.
Dann ist dein Buch schlecht.
Die Erklärung ist nämlich recht simpel:
Aber Gregor hat mir die Antwort schon weggenommen
[quote]
Ich würde gerne einen Überblick haben, was bei Java (als Anfänger) nicht sehr leicht ist.
[quote]
Dann hast du dir noch nicht C oder C++ angesehen.
Java ist nämlich recht schlank und auch recht simpel. Zumindest als Anfänger. Natürlich kann Java auch kompliziertere Sachen - aber welcher Anfänger braucht schon Reflexion & Co?Raucher beklagen sich über die so hohen Zigarettensteuer, aber wer zwingt sie zum Rauchen, was ausserdem dumm ist?!
Verstehst du was ich meine?!
Nein. Der Vergleich hinkt.
Nikotin ist ein Suchtgift. Du fängst einmal an und dann hat es dich. Aufhören ist nur schwer möglich.Wenn ich rechnen lerne, dann lerne ich es mit Stift und Papier und rechne nicht alles mit einem TR.
Wenn man nicht die Disziplin hat das so durchzuziehen sondern immer wieder zum TR greift - dann wird man nie gut rechnen können. Disziplin gehört halt zum programmieren dazu.
Für Fortgeschrittene und Profis ist es allemal spitze!
Und Anfänger verwenden diese 'Features' einfach nicht.
Mit welcher Sprache sollte man denn Anfangen? Es gibt doch für nahezu alle Sprachen irgendwelche Bibliotheken die diese grundlegenden Dinge bereitstellen. Wenn ich faul bin und nichts lernen will, kann ich auch ohne viel Ahnung von C zu haben dort ne Linked List implementieren. Warum? Weil ich Copy&Paste beherrsche...
Und ob ich diese Linked List per Copy&Paste in mein Programm einbaue, oder per #include <list> oder sie selber schreibe ändert das Resultat nicht. Nämlich das Resultat: ich habe eine Linked List.
Der Unterschied ist lediglich der: nur bei Punkt 3 habe ich wirklich etwas dabei gelernt.
Aber wenn ich nicht lernen _will_ - dann kann man mich auch nicht dazu zwingen.
-
Shade Of Mine schrieb:
Allerdings bietet Java hier den Vorteil, dass es 'Fehlertoleranter' ist.
zB wenn du über die Grenzen eines Arrays schreibt wirft Java ne Exception, ein C++ Programm schmiert ab.Also ich würde das eher als "Intoleranter gegenüber Fehlern" bezeichnen.
Shade Of Mine schrieb:
Aber Gregor hat mir die Antwort schon weggenommen
Ätsch! :p :p :p
Shade Of Mine schrieb:
Natürlich kann Java auch kompliziertere Sachen - aber welcher Anfänger braucht schon Reflexion & Co?
1. Ich. ...und natürlich bin ich noch Anfänger. Ich habe ja noch nichtmal ein vernünftiges Programm fertiggestellt.
2. Eigentlich sind Reflection & Co garnicht so kompliziert. Das einzige, was ich momentan an Java kompliziert finde, sind die Möglichkeiten, die sich jetzt mit den Generics ergeben. Ich komme da momentan noch nicht so ganz mit der Denkweise zurecht, so dass ich teilweise nur mehr oder weniger auf "gut Glück" programmiere. Zum Beispiel bin ich mir momentan nicht sicher, ob ich das Aussehen einer von der folgenden abstrakten Klassen abgeleiteten nicht-generischen Klasse durch die Generics wirklich so genau festgelegt habe, wie ich es wollte:
package math; public abstract class FieldElement<Element extends FieldElement<Element,F>, F extends Field<Element>> { public abstract Element getAdditiveInverseElement(); public abstract Element getMultiplicativeInverseElement(); public abstract Element sumWith(final Element element); public abstract Element multiplyWith(final Element element); public abstract F getField(); public final Element getAdditiveNeutralElement() { return getField().getAdditiveNeutralElement(); } public final Element getMultiplicativeNeutralElement() { return getField().getMultiplicativeNeutralElement(); } }
Kann mir einer von euch sagen, ob das "eindeutig genug" ist? Eine davon abgeleitete Klasse "KonkretesKörperElement" soll genau so aussehen:
public class KonkretesKörperElement extends FieldElement<KonkretesKörperElement,KonkreterKörper> { //... }
und KonkreterKörper:
public class KonkreterKörper extends Field<KonkretesKörperElement> { //... }
...ok, ich sehe ein, dass ich gerade abschweife.
-
Hi,
Optimizer schrieb:
Das wird sich mit Java 1.5 zum Glück (wenigstens scheinbar) ändern. Die schlechte Performance dieser Vorgehensweise bleibt.
Echt schade, da hat man echt eine Riesenchance verpasst. Es lebe C#! :pKannst du bitte genauer erläutern, was du damit meinst?
Wird für Real aber auch zu komplex sein.
Du Clown.
-
Real schrieb:
Hi,
Optimizer schrieb:
Das wird sich mit Java 1.5 zum Glück (wenigstens scheinbar) ändern. Die schlechte Performance dieser Vorgehensweise bleibt.
Echt schade, da hat man echt eine Riesenchance verpasst. Es lebe C#! :pKannst du bitte genauer erläutern, was du damit meinst?
Ab Java 1.5 gibt es das sogenannte "Autoboxing/Autounboxing". Damit wird implizit dafür gesorgt, dass ein primitiver Typ in einen Wrappertyp verpackt wird und andersherum, wenn dies erforlderlich ist.
Wenn du bisher folgenden Code hattest:
int i = 456; Integer integer = new Integer(i);
Dann kannst du das ab Java 1.5 auch so schreiben:
int i = 456; Integer integer = i;
Ich bin nicht wirklich von diesem Feature begeistert, weil hierdurch Dinge implizit gemacht werden, die besser explizit geblieben wären. Wenn ein Schritt viel Zeit kostet, dann soll dieser Schritt im Code IMHO durchaus etwas unangenehmer sein. Ich sehe nicht, dass das bischen Codeersparnis das wert ist.
-
Hi Shade of Mine,
gut, kann sein, dass Java gegenüber C++ schlank wirkt, aber was ist dann C?
Gerade weil C so extrem schlank ist, halte ich es für sehr angebracht es als erstes zu lernen.
Mein Gott, die typischen Fehler wie z.B. BufferOverflow merkt man doch schnell.
Ich habe auch mal gezielt ein BufferOverflow in einen Array gemacht und ich fand das auch irgendwie cool!
Bevor ich in der Schule Java gelernt habe, habe ich mich einige Monate vorher etwas mit C++ beschäftigt. Ich kam dann auch bis zu dem Gebiet Zeiger.
Egal, was ich in C/C++ implementiert habe, es war doppelt so einfach wie in Java!1. Schnell implementiert, wegen kurze Befehle!
2. Es ist unglaublich logisch!
3. Bin ich motivierter es zu lernen, da mir mehr Freiheiten offen stehen (nenn mich von mir aus Masochist) und ich mehr Möglichkeiten habe (z.B. hardwarenah programmieren)
Jojo
Das war´s meinerseits.
Mich würde interessieren, warum du eher C++ preferierst (denk ich jetzt mal) als Java.
Liebe Grüße
Real
-
@Gregor:
Ich finde es nicht gerade sehr sinnvoll, eine generische Klasse beim Ableiten in ihrer Generizität einzuschränken.
Geht das überhaupt gut?Außerdem ist mir nicht klar, warum du zwischen verschiedenen Elementen unterscheidest. Ein Körper wird doch dadurch definiert, dass die Menge der Elemente (beliebige Elemente!) über zwei Operationen bestimmte Voraussetzungen erfüllen. Die Elemente selber könnten jedoch auch Mitglieder eines ganz billigen Gruppoiden sein. Dort gibt es halt dann kein multiplikativ inverses Element, aber das ist doch Sache der Struktur und nicht der Elemente.
Genauso wie die Rechenoperationen eigentlich Sache der Struktur sind und nicht der Elemente -> ich würde add und mult nicht in die Elementklasse tun.
Ist natürlich dann schwierig für konkrete Elemente und Rechenoperationen verschiedene Operationen anzubieten und wahrscheinlich geht es gar nicht anders als wie du es grad machst. Aber es ist schon spät und ich wollte einfach nur unkontrolliert rumkritisieren.@Real: In C# werden primitive Typen bei der Benutzung von Generics nicht verpackt, sondern es wird für alle primitiven Typen ein eigener Native Code zur Laufzeit erstellt. Dadurch fällt das ständige einpacken und auspacken weg, was wirklich hardcore ineffizient ist.
Außerdem werden die Generics nicht so realisiert, dass man z.B. einen Container von Object-Elementen hat, wo nur der Compiler automatisch 932478657 Typecasts hinsetzt. Gut, ich kann jetzt keinen Typfehler mehr machen. Aber die dadurch eigentlich unnötigen Typecasts stehen trotzdem im Bytecode, weil die VM sonst kreischt.
-
Optimizer schrieb:
@Gregor:
Ich finde es nicht gerade sehr sinnvoll, eine generische Klasse beim Ableiten in ihrer Generizität einzuschränken.
Geht das überhaupt gut?Natürlich ist das sinnvoll und natürlich geht das gut. Das zeigt doch dieses Beispiel!
Noch Fragen?
Optimizer schrieb:
Außerdem ist mir nicht klar, warum du zwischen verschiedenen Elementen unterscheidest. Ein Körper wird doch dadurch definiert, dass die Menge der Elemente (beliebige Elemente!) über zwei Operationen bestimmte Voraussetzungen erfüllen.
Es geht darum, dass der Körper bezüglich dieser beiden Operationen abgeschlossen ist. Ich möchte nicht, dass es möglich ist, eine Klasse von meiner abstrakten Körperklasse bzw. der Körperelementklasse abzuleiten, die die Abgeschlossenheit bezüglich dieser beiden Operationen verletzt.
-
Optimizer schrieb:
@Real: In C# werden primitive Typen bei der Benutzung von Generics nicht verpackt
Oh, sind die Generics bei C# inzwischen schon da? Habe ich da etwas verpaßt?
-
Gregor schrieb:
Optimizer schrieb:
@Real: In C# werden primitive Typen bei der Benutzung von Generics nicht verpackt
Oh, sind die Generics bei C# inzwischen schon da? Habe ich da etwas verpaßt?
In einem Jahr. Sind sie bei Java schon aus dem Beta-Status raus? Hab ich was verpasst?