- Sind Primitive erhaltenswert?
- Sollen alle veralteten Inhalte gelöscht werden?
- Brauchen wir 2 GUI-Frameworks?
- ...
Antworten
Zu viele Anzeigen?Aus Kompatibilitätsgründen können sie das nicht mit den Standard-Java-Versionen tun. Es gibt derzeit so viel Java-Software in der Produktion, dass man sie nicht einfach mit einer neuen Version zerstören kann, die den ganzen Mist entfernt.
Ich denke jedoch, dass Sun eine "Java X"-Version erstellen könnte, die alles entfernt, was mangelhaft ist, und all die guten und nützlichen APIs hinzufügt, die es gibt, die aber derzeit nicht enthalten sind (einschließlich des Ersatzes von Java-APIs, für die es bessere Alternativen gibt, z.B. log4j, und fangen wir nicht mit Datum und Kalender an). Diese Version ist nicht dazu gedacht, Java zu ersetzen, sondern könnte als Ziel für neue Softwareprojekte dienen. Ich schätze, sie könnten auch die Sprache verbessern, um fehlende Funktionen einzubauen, die Java im Vergleich zu den neuesten Versionen von C# usw. etwas mickrig aussehen lassen. Wenn sie auch ein Tool für die Codeportierung entwickeln würden, das alle Problembereiche in einer Codebasis beheben oder zumindest mit "FIXME" versehen könnte ...
Man muss zugeben, dass Microsoft gute Arbeit leistet, wenn es darum geht, die Leute auf neuere Versionen von .NET umzustellen, wenn diese herauskommen. Sun hat hier völlig versagt, wenn man die Anzahl der Anwendungen betrachtet, die noch auf 1.4 laufen, und die lethargische Java-Versionspolitik vieler Unternehmen (die anscheinend froh sind, wenn ihre .NET-Leute irgendwie das Neueste und Beste verwenden können). Angesichts der Tatsache, dass es einfach ist, mehrere Java-Installationen auf einem Rechner zu haben, denke ich, dass mehr getan werden sollte, um Unternehmen und Softwarehäuser zu ermutigen, früher zu aktualisieren.
Wie Pat schon sagte, verläuft die Einführung der neuesten JDK-Version recht langsam, und viele Anwendungen laufen derzeit mit alten (manchmal wirklich alten) Java-Versionen.
Daher glaube ich nicht, dass es einen wirklichen Vorteil bringt, die Abwärtskompatibilität nicht zu gewährleisten.
Was Ihre Vorschläge angeht, sehe ich nicht wirklich das Interesse, die Primitive zu entfernen. Natürlich gibt es seit Java 5 Autoboxing. Allerdings haben Primitive immer noch ihre Interessen...
Ein Bruch der Kompatibilität würde Sinn machen, wenn die JVM gleich bleibt. In diesem Fall würde das "neue" Java zu einer neuen, anderen Sprache werden, die auf der JVM läuft, wie zum Beispiel die folgenden dort . Glücklicherweise garantiert die Art und Weise, wie die JVM konzipiert ist, die Interoperabilität zwischen Sprachen und Versionen, so dass ich denke, dass die Auswirkungen begrenzt sein würden.