Java Timeline: Geschichte der Entwicklung der Java Technologie
- Themenstarter Thomas Darimont
- Beginndatum
genodeftest
Erfahrenes Mitglied
Zeigt natürlich nur die guten/besten Ereignisse. Wäre mal interessant, wie sich Oracle die Zukunft von Java vorstellt, und zwar weiter als Version 8 …
Meiner Meinung nach ist es nämlich an der Zeit über ein Release nachzudenken, das nicht mehr vollständig abwärtskompatibel ist und einiges an Ballast beseitigt:
• deprecated Methoden / Klassen
• AWT und Swing, sofern JavaFX deren Anwendungsgebiete übernimmt, ansonsten eine Grundlegende Überarbeitung dieser APIs
• fehleranfällige Methoden, Funktionalitäten wie z.B. die paint()-Methoden, die in Swing-Komponenten sichtbar sind, obwohl sie das nicht sein sollten
• den Datentyp short, der erfahrungsgemäß nicht verwendet wird
• die Fähigkeit, dass jedes Objekt einen Monitor halten kann (massive Performancevorteile, wer Synchronisation braucht, kann genauso mit Locks oder einer speziellen Schnittstelle arbeiten)
sowie:
• Änderung der API (hauptsächlich Sichtbarkeiten) bei Methoden/Klassen/…, bei denen in den Kommentaren explizit davon abgeraten wird, diese zu verwenden, weil sie nur für interne Zwecke gedacht sind. Diese Methoden/Klassen/… könnte man in ihrer Sichtbarkeit beschneiden.
Meiner Meinung nach ist es nämlich an der Zeit über ein Release nachzudenken, das nicht mehr vollständig abwärtskompatibel ist und einiges an Ballast beseitigt:
• deprecated Methoden / Klassen
• AWT und Swing, sofern JavaFX deren Anwendungsgebiete übernimmt, ansonsten eine Grundlegende Überarbeitung dieser APIs
• fehleranfällige Methoden, Funktionalitäten wie z.B. die paint()-Methoden, die in Swing-Komponenten sichtbar sind, obwohl sie das nicht sein sollten
• den Datentyp short, der erfahrungsgemäß nicht verwendet wird
• die Fähigkeit, dass jedes Objekt einen Monitor halten kann (massive Performancevorteile, wer Synchronisation braucht, kann genauso mit Locks oder einer speziellen Schnittstelle arbeiten)
sowie:
• Änderung der API (hauptsächlich Sichtbarkeiten) bei Methoden/Klassen/…, bei denen in den Kommentaren explizit davon abgeraten wird, diese zu verwenden, weil sie nur für interne Zwecke gedacht sind. Diese Methoden/Klassen/… könnte man in ihrer Sichtbarkeit beschneiden.
