Sollte Java die Rückwärtskompatibilität in zukünftigen Versionen zugunsten einer saubereren Sprache aufgeben?

Question

• Sind Primitive erhaltenswert?
• Sollen alle veralteten Inhalte gelöscht werden?
• Brauchen wir 2 GUI-Frameworks?
• ...

Answer 1

Ich habe bereits erwähnt auch in seinem Wie und wann APIs veraltet sein sollten Es wird nichts über eine Politik gesagt, die sich auf die tatsächliche entfernen die veralteten APIs...

Die Zahl der Anwendungen, die auf älteren JVM (z. B. 1.4) basieren, ist immer noch hoch, was zum Teil darauf zurückzuführen ist, dass Anwendungsserver die lange Zeit brauchen, um sich mit neuen Versionen der JVM zu validieren...

Die schiere Anzahl der Anwendungen, die tatsächlich in der Produktion laufen, bedeutet, dass diese "Abwärtskompatibilitäts"-Politik möglicherweise nicht so bald durchbrochen wird.

Answer 2

Es gibt mehrere Arten der Abwärtskompatibilität:

1. Kann alter Quellcode mit dem neuen Compiler kompiliert werden?

   Dies lässt sich mit Werkzeugen bewerkstelligen, die alte Konstrukte in neue umwandeln, oder mit einer Direktive wie "source 1.6;" am Anfang der Datei.

2. Können alte Klassendateien in einer neuen JVM ausgeführt werden?

   In meiner Welt ist das ein absoluter Show-Stopper. Wir verwenden so viele Bibliotheken von Drittanbietern, dass es zu kostspielig wäre, ein gleichzeitiges Upgrade für alle zu erzwingen.

   Dies ist auch der Grund dafür, dass veraltete Klassen und Methoden nicht entfernt werden, allerdings in geringerem Maße.

3. Können alte Klassendateien Code aufrufen, der mit dem neuen Compiler kompiliert wurde?

   Dies ist ein wichtiger Teil von #2, wegen der Rückrufe.

4. Kann neu kompilierter Code Code aus alten Klassendateien aufrufen?

   Ein weiterer wichtiger Teil von #2.

5. Sieht der Code für Entwickler im Wesentlichen ähnlich aus?

   Dies ist wichtig für die Ausbildung und für die Arbeit mit großen Codebasen, die noch nicht vollständig konvertiert sind. Ein subtilerer Aspekt ist, wie viel von der neuen Funktion in einer gemischten Codebasis verwendet werden kann. Wenn Sie das zu weit treiben, haben Sie etwas wie Scala statt Java++.

Die Generika wurden so hinzugefügt, dass die alle dieser Arten der Kompatibilität. Ich denke, dass jede inkompatible Änderung an Java mindestens die Punkte 2, 3 und 4 beibehalten muss, um überhaupt eine Chance auf Akzeptanz zu haben als Java . Werkzeuge für den Umgang mit der Nummer 1 sind ebenfalls eine Mindestanforderung.

Answer 3

Sie können dies mit Hobby- (Ruby) und wenig implementierten (Python) Sprachen tun, aber Sie können sich nicht vorstellen, wie viele Anwendungen auf der Welt in Java geschrieben werden. Schauen Sie einfach bei Freshmeat oder Sourceforge nach. Und das ist nur ein Teil davon. Also nein, das ist keine gute Idee. Eigentlich wäre es eine ziemlich dumme Idee.

Es gibt nicht zwei GUI-Frameworks. Swing hängt von AWT ab und nutzt es als Basis.

Answer 4

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.

Answer 5

Ich würde es sehr begrüßen, wenn bestimmte veraltete Funktionen entfernt würden - zum Beispiel, wenn die Date Objekt wirklich unveränderlich gemacht würde, wäre ich sehr glücklich. Wenn Sie eine unveränderliche Klasse schreiben, können Sie nicht davon ausgehen, dass Datumswerte unveränderlich sind, und müssen sie beispielsweise defensiv kopieren, und Sie können sie nicht zuverlässig als Schlüssel in Hashmaps verwenden (da in beiden Fällen anderer Code das Datum verändern kann, unabhängig davon, ob die Methoden als veraltet gekennzeichnet sind oder nicht).

Wenn es darum geht, neue Sprachfunktionen hinzuzufügen, verstehe ich das Mantra der Abwärtskompatibilität nicht ganz. Meiner Meinung nach ist es nicht so schlimm, wenn Code, der für eine frühere Version geschrieben wurde, einige Anpassungen benötigt, um in einer späteren Version zu laufen. Zwischen 1.5 und 1.6 wurden der Schnittstelle ResultSet zusätzliche Methoden hinzugefügt, so dass Code, der unter Java 1.5 kompiliert und ausgeführt werden konnte, unter 1.6 nicht einmal mehr kompiliert werden konnte.

Ist es vernünftig, von einer Anwendung, die seit 5 Jahren nicht mehr aktualisiert wurde, zu erwarten, dass sie auf der neuesten Version der JVM perfekt läuft? Wenn Unternehmen immer noch Java 1.4 und Anwendungen, die dafür geschrieben wurden, verwenden, ist es dann wirklich wichtig, was in Java 7 kommt? Die Aufhebung der Abwärtskompatibilität bedeutet nicht, dass alle früheren Versionen von JVMs ebenfalls nicht mehr funktionieren. Wenn die Anwendung auf eine frühere Version ausgerichtet ist, kann man sie ohne Bedenken auf dieser Version der JVM ausführen.

Am wichtigsten ist, dass mit der Zeit, wenn die Menschen Java benutzen, Fehler und Funktionslücken offensichtlich werden, deren Korrektur/Implementierung ein großer Segen wäre. Es ist unglücklich, bei dem Versuch, die Sprache zu verbessern, in eine Zwangsjacke gesteckt zu werden, weil das, was vorher da war, schon da war, und meiner Meinung nach keine grundlegende Voraussetzung.

Natürlich müsste man sich auch Gedanken über den Weg der Aufrüstung machen. Eine plötzliche Umstellung von Ints auf Integers würde zum Beispiel eine Menge mühsamer Codeänderungen für alle erfordern (sowie das Hinzufügen zusätzlicher Nullprüfungen usw.). Das Hinzufügen einer neuen Funktion, die zufällig die Abwärtskompatibilität bricht (z.B. Closures), oder das Entfernen von Methoden, die seit Jahren veraltet sind, hat jedoch kaum Auswirkungen auf den bestehenden Code. (Wenn Sie veraltete Methoden verwendet haben, dann hätten Sie sie vorher entfernen sollen, aber jetzt sind Sie dazu gezwungen!)