Java erweitert sich mit neuen trendigen Mechanismen, und mit ihm wächst sein Grab mit veralteten Funktionen wie Vector, Finalization, NashornScriptEngine, SecurityManager und Unsafe. Wie wird das Grab gefüllt? Java gedeiht und wächst und sammelt neue Funktionen, APIs und Module, aber gleichzeitig verliert es von Zeit zu Zeit seine alte Haut.Einige Teile erweisen sich als überflüssig, andere passen nicht mehr zu modernen Aufgaben, und einige sind immer als Kludges gedacht.All diese veralteten oder entfernt Mechanismen füllen still und stetig das Grab von Java. Werfen wir einen Blick auf einige von ihnen. Was ist drin im Grab? Legacy Sammlungen Zurück in die Zeiten, bevor Java , der oder Die Wildnis , der und Im Gegensatz zu allen nachfolgenden Antiquitäten ist diese veraltete API nicht als Aber gleichzeitig ist die für jede Klasse schreit "NICHT mich benutzen!" Auf der Weite des Internets, diese veralteten Klassen werden in der Regel genannt . List Deque Map Vector Stack Dictionary Deprecated Dokumentation legacy collection classes Aber warum sind sie veraltet? Legacy-Kollektionen haben zwei Hauptnachteile: 
 
 
 Alle Interaktionspunkte mit diesen Klassen sind synchronisiert. Die Klassen haben keine gemeinsamen Schnittstellen und erfordern einen individuellen Ansatz. Gehen wir in Ordnung. Der erste Nachteil ist**, dass alle Interaktionspunkte mit diesen Klassen synchronisiert sind.** Es fühlt sich jedoch eher wie ein Vorteil an als das Gegenteil an. Schließlich ist sicheres Multithreading immer eine gute Sache. Aber was ist, wenn diese Sammlungen in einem Single-Thread-Kontext verwendet werden? Synchronisierungen reduzieren einfach die Leistung, ohne echte Sicherheitsvorteile zu bieten. Dies spiegelt sich deutlich in modernen Java-Praktiken wider, bei denen Entwickler Sammlungen lieber kopieren als sie ändern. Der zweite Nachteil** ist, dass Klassen keine gemeinsamen Schnittstellen haben und einen individuellen Ansatz erfordern.** Dies führt zu einem Problem, das so alt ist wie die Programmierung selbst: nicht-universeller Code. Stellen Sie sich vor, dass wir ein Entwickler sind, der an einer alten Java-Version arbeitet, und wir haben Code, der mit Zum Beispiel, hier ist eine: Stack Stack<Integer> stack = new Stack<>();

for (int i = 0; i < 5; i++) {
    stack.add(i);
}

System.out.println(stack.pop());
 Im Moment ist der Code ohne Hitch, aber stellen Sie sich vor, dass er bis zu 1.000 Zeilen mit 150 Referenzen auf die variabel zu sein. stack Dann schickten Kunden eines Tages ein Fax an uns und sagten, dass sie sehr langsam gearbeitet haben (die Codeblöcke, nicht die Kunden). enthält ein Array zum Speichern von Elementen, und dieses Array selbst wird zu oft wiederhergestellt. Stack Wir überlegen und stellen eine Theorie vor: Die verknüpfte Liste kann dazu beitragen, die App-Leistung um das 100-fache zu steigern! auf dem Internet – und dann unsere Handschuhe rollen, um alle 150 Referenzen zu kopieren und zu Kein Wunder, aber wir sehen keinen anderen Ausweg. LinkedList stack Gehen wir zur Gegenwart, wo unser Code so aussieht: Deque<Integer> deque = new ArrayDeque<>();
IntStream.range(0, 5)
        .forEach(deque::addLast);
System.out.println(deque.pollLast());
 Im Laufe der Zeit wächst der Code auch auf 150 Referenzen, aber jetzt hat er Referenzen Wir folgen demselben Weg und stellen auch die Theorie vor, dass es schneller mit einer verlinkten Liste sein wird. Zwei Die auch implementiert Und das ist alles, was es braucht! deque ArrayDeque LinkedList Deque Das ist genau, wie die Es hilft zu vermeiden, an bestimmte Implementierungen gebunden zu sein. Zum Beispiel sind Entwickler nicht mehr in etwas wie  and can use the  Interface statt. Sammlungsrahmen Vector List Fertigstellung Zu einer Zeit, (in der ) schien wie eine ausgezeichnete Idee: eine Methode, die angerufen werden würde, wenn ein Objekt zerstört wurde und Systemressourcen freigab. Finalisten #finalize() Aber in der Praxis war diese Idee nicht so brillant: 
 
 
 
 
 Der Finalisierer wird möglicherweise überhaupt nicht angerufen, wenn es irgendwo noch einen Hinweis auf das Objekt gab oder wenn der Müllsammler es nicht löschen wollte. Wenn der Müllsammler das Objekt zerstören wollte, musste er noch warten, bis dieser Code ausgeführt wurde. Das Objekt kann sich selbst wiederbeleben. Am schlimmsten ist, dass die Finalisierer perfekte Bedingungen für Gedächtnislecks geschaffen haben. Modern Java ist sehr flexibel; selbst der Müllsammler kann von jeder Art sein und auf unterschiedliche Weise konfiguriert werden. Und vergessen Sie nicht, dass der Müllsammler garantiert nicht eine Instanz sammeln wird, solange sie mindestens eine starke Referenz hat. Aus diesen Gründen sollte die Logik der Freigabe von Systemressourcen nicht vom Lebenszyklus des Objekts abhängen. Wenn wir uns die Dokumentation für die Methode, sehen wir, dass es empfohlen wird, die Es wurde speziell entwickelt, um Ressourcen effizient freizugeben, ohne den Müllsammler zu betreiben. um es zu tun. #finalize() AutoCloseable Nicht zu vergessen Was die Verfolgung betrifft, wenn ein Objekt tatsächlich gelöscht wird, bietet Java eine Alternative: , die die oben beschriebenen Probleme löst. java.lang.ref.Cleaner Lassen Sie uns für Klarheit mit Java-Speicher spielen und einen unsicheren Code mit einem Finisher schreiben: class ImmortalObject {  
    private static Collection<ImmortalObject> triedToDelete = new ArrayList<>();

    @Override  
    protected void finalize() throws Throwable {
        triedToDelete.add(this);
    }  
}
 Hier erwecken wir buchstäblich jeden Fall von dass der Müllsammler zu löschen ist, was Ihrem RAM oder Ihnen selbst nicht gefallen wird, wenn es mit einem . ImmortalObject OutOfMemoryError So sieht der entsprechende Code aus : Cleaner static List<ImmortalObject> immortalObjects = new ArrayList<>();

....

var immortalObject = new ImmortalObject();  
Cleaner.create()  
        .register(  
                immortalObject,  
                () -> immortalObjects.add(immortalObject)  
        );
 Es ist erwähnenswert, dass wir auch die Löschung von absolut jedem vorhandenen Objekt hören können. Stop! Have we just learnt why that approach is problematic? That's true, but it's only bad with resource management. Sometimes a Java application still needs to know that the garbage collector deletes an object. Like for what? For example, to create an optimized cache. Die Klasse lebt noch bis zu ihrem Namen, aber nicht, weil wir sie zu einer statischen Liste hinzufügen, wenn wir die Instanz löschen. Dies wirkt, wie der Zuhörer hier eine Bezugnahme auf Jetzt wird das Objekt nicht wiederbelebt, weil der Müllsammler die Instanz nicht löschen wird. Es ist idiomatischer in Java und es ist keine Nekromancy beteiligt. Runnable immortalObject Finalizer wurden häufig bei der Arbeit mit Objekten verwendet, die über JNI irgendwo außerhalb des Java-Codes erstellt wurden, zum Beispiel in C++. Aber der Mechanismus war unsicher, und die Finalizer wurden schließlich durch eine viel elegantere Alternative ersetzt. NashornSchreibmaschine Wenige erinnern sich, dass Java einst buchstäblich mit JavaScript Schritt gehalten hat: JDK 8 verfügte über die integrierte JS-Engine, mit der Entwickler JS-Code direkt aus Java ausführen können. Nashorn Wir könnten dieses sehr beliebte Banana-Puzzle implementieren, ohne Java zu verlassen: new NashornScriptEngineFactory()
        .getScriptEngine()
        .eval("('b' + 'a' + + 'a' + 'a').toLowerCase();");
 Tatsächlich ist es eine coole Sache, aber nur, bis wir erkennen, dass Java-Entwickler die JavaScript-Engine aufrechterhalten müssen. Nashorn konnte nicht mit der schnellen Entwicklung von JavaScript Schritt halten, und Polyglot-Lösungen erschienen, wie GraalVM Polyglot. Diese Faktoren führten dazu, dass der Motor nach nur vier Sprachversionen (in Java 11) veraltet wurde, und nach einer Weile wurde er schließlich für Java 15. Über Bord geworfen Während Nashorn JavaScript über Java implementiert hat, schafft Polyglot eine ganze JVM-basierte Plattform, die nativ mehrere Sprachen, einschließlich Java und JavaScript, unterstützt. Sicherheitsmanager Treffen Sie einen anderen alten Timer, der bis Java 17 überlebte. . SecurityManager In den Tagen der wilden Applets, als Java-Code direkt im Browser ausgeführt werden konnte, Es war der Rückgrat der Java-Anwendungssicherheit. SecurityManager 
 
 Ein Applet ist ein kleines Programm, das direkt in einem Browser läuft und Animationen, Grafiken oder interaktive Elemente anzeigen kann, aber unter strengen Einschränkungen funktioniert. Ein Applet ist ein kleines Programm, das direkt in einem Browser läuft und Animationen, Grafiken oder interaktive Elemente anzeigen kann, aber unter strengen Einschränkungen funktioniert. Aber die Zeit vergeht, wild schließlich von Browsern auf Desktops migriert, und dann starb komplett als Lösung. wurde und wurde häufig in Unternehmensanwendungen eingesetzt. Applets SecurityManager ist Aber nichts dauert ewig, und der Grim Reaper kam Java 17 entfernte sein gesamtes Interieur und hinterließ nur die Fassade ohne jegliche Logik. Wir werden nur den Platzhalter finden: SecurityManager SecurityManager @Deprecated(since = "17", forRemoval = true)
public static void setSecurityManager(SecurityManager sm) {
    throw new UnsupportedOperationException(
             "Setting a Security Manager is not supported");
}
 Vollbildmodus Eintritt Vollbildmodus Eintritt Vollbildmodus Wie hat Es fungierte als interne JVM-Wache, die potenziell gefährliche Operationen abhörte und überprüfte, ob jedes Stack-Element das Recht hatte, eine solche Aktion durchzuführen. SecurityManager Was genau tat Die Liste ist riesig, also schlage ich vor, wir schauen uns nur die Hauptpunkte an: SecurityManager 
 
 
 
 
 
 Zugriff auf das Dateisystem; die Netzwerkverbindungen; Erstellung und Fertigstellung von Prozessen; Zugriff auf Systemeigenschaften; Manipulation mit Klassen und Reflexion. Es funktionierte gut in den Tagen der Browser-Applets, wo es notwendig war, unzuverlässigen Code in einer Sandbox zu halten, aber mit der Entwicklung der Containerisierung wurde es veraltet. SecurityManager Obwohl ursprünglich für Applets erstellt wurde, wurde es auch in anderen Kontexten verwendet. In unserem PVS-Studio statischen Analyzer half es, ein lustiges Problem zu lösen: Wenn der statische Klasseninitialisierer im analysierten Code Der Analysevorgang wird beendet. Es erlaubte uns, solche Operationen bei der Analyse statischer Felder zu blockieren, und etwas, das wir später durch ASM ersetzten. SecurityManager unterstützt System#exit SecurityManager Übrigens, obwohl Applets als Ansatz früher als Sie haben gerade erst begonnen, aus der JDK entfernt zu werden. SecurityManager Die Welt verändert sich, die Ansätze ändern sich und geht es weg. SecurityManager Unsicher Java beseitigt Unsicherheit. Vielleicht der legendärste Bewohner dieses Grabes war . sun.misc.Unsafe Diese Klasse war ein geheimes Tor in die JVM-Tiefen, wo die üblichen Sprachregeln nicht mehr in Kraft waren. kann eine Java-Anwendung leicht abstürzen . Unsafe SIGSEGV Wie? wie zum Beispiel so: class Container {
    Object value; // (1)
}

// ✨ some magic to get unsafe unsafely ✨
Unsafe unsafe = ....;

long Container_value =
  unsafe.objectFieldOffset(Container.class.getDeclaredField("value"));

var container = new Container();

unsafe.getAndSetLong(container, Container_value, Long.MAX_VALUE); // (2)
System.out.println(container.value); // (3)
 In der Feld (1), wir setzen 2) Anstelle von und versuchen, den Wert zu (3) Die value Long.MAX_VALUE Object System.out Die virtuelle Maschine liebt diesen Trick nicht, und sie stürzt auf der letzten Linie, weil enthält Müll statt einer echten Bezugnahme auf das Objekt. Und dies ist nur ein Beispiel für einen so leicht zu finden Fehler. value Aber warum wurde Java ein so gefährlicher Mechanismus hinzugefügt? Er wurde nicht als Anarchist geboren, sondern als Erlöser. und (wir werden später über sie sprechen), mussten die Standardbibliotheken Operationen auf niedriger Ebene wie Speichermanagement, atomare Operationen oder das Blockieren von Threads effizient durchführen. Unsafe VarHandle MemorySegment Aber wie können wir all das oben tun, wenn die Sprache verbietet, unter den Hut zu schauen? Er erschien als ein für die eigenen Bedürfnisse von Java. Unsafe internal Die Entwickler beabsichtigten, es nur innerhalb von Java zu verwenden – und es hatte sogar Schutz gegen den externen Zugriff auf seine Instanz. Siehe die Magie, die eine "Unsicherheit" auf unsichere Weise fängt: Unsafe var Unsafe_theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
Unsafe_theUnsafe.setAccessible(true);
Unsafe unsafe = (Unsafe) Unsafe_theUnsafe.get(null);
 Dieses Objekt ermöglicht es uns, die virtuelle Maschine so sehr zu quälen, wie wir wollen. Aber beeilen Sie sich nicht, die Entwickler zu kritisieren, die es wagten, zu erreichen, was Java so hart versuchte, vor ihnen zu verbergen; es lohnt sich, sich daran zu erinnern: der Zugang zu Es hat vielen Bibliotheken geholfen, effizienter zu werden. Zum Beispiel wurde die beliebte Netty-Bibliothek für die Arbeit mit Netzwerken gezwungen, Und als ein Ersatz kam, Netty Zwei das. Unsafe Unsafe Wechseln Von welcher Art von Ersatz sprechen wir? Es gibt nicht einen, sondern zwei: 
 
 
 Die Foreign Function & Memory API ersetzt die Speicheroperationen. VarHandle API ersetzt atomare Operationen. Diese APIs beschränken sich nicht darauf, einfach bestimmte Methoden in Sie sind leistungsstarke Tools für die sichere Arbeit mit Low-Level-Operationen. Zum Beispiel ermöglicht die Foreign Function & Memory API das Anrufen nativer Funktionen, ohne das anstrengende JNI zu verwenden! Unsafe Die Unsicherheit von Java verblasst langsam in Vergessenheit und hinterlässt neue, gut gestaltete und leistungsstarke APIs, die dasselbe tun, ohne Angst vor der bedingten . SIGSEGV Warum ist das Grab voll? Java wächst, verliert veraltete Ideen, wird sicherer, sauberer und einfacher.Jede neue API ist nicht nur "ein weiteres Modul hinzuzufügen", sondern alte Lücken auf eine anspruchsvollere Weise zu schließen. Gleichzeitig spielt das virtuelle "Tomb" eine wichtige kulturelle Rolle: Es dokumentiert die Entwicklung von Ideen und Entscheidungen, erinnert uns an den Weg, den wir gegangen sind und bildet den Kontext, der für die sinnvolle Plattformentwicklung erforderlich ist.

Read My Stories

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Java's Growing Graveyard: Die alten APIs werden begraben - und was sie ersetzt hat

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Wir feiern die Community unserer Technologieunternehmen!

HackerNoon Decoded 2024: Celebrating Our Management Community!

This Black Friday & Holiday Season, HackerNoon Has Your Tech Marketing Covered 🎁 💚

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Wir feiern die Community unserer Technologieunternehmen!

HackerNoon Decoded 2024: Celebrating Our Management Community!

This Black Friday & Holiday Season, HackerNoon Has Your Tech Marketing Covered 🎁 💚

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps