Java ekspanderer med nye trendy mekanismer, og sammen med det vokser dens grav med forældede funktioner som Vector, Finalization, NashornScriptEngine, SecurityManager og Unsafe. Hvordan er graven fyldt op? Java blomstrer og vokser, akkumulerer nye funktioner, API'er og moduler, men samtidig smider det sin gamle hud fra tid til anden.Nogle dele viser sig at være overflødige, andre passer ikke længere til moderne opgaver, og nogle er altid beregnet som kludge. Lad os se på nogle af dem. Hvad er der inde i graven? Legacy samlinger Tilbage i de dage, før Java havde , der eller Vilde , der og I modsætning til alle efterfølgende antikviteter er denne forældede API ikke markeret som Men på samme tid, den for hver klasse råber "DON'T USE ME!" På internettets vidstrækkelse kaldes disse forældede klasser normalt . List Deque Map Vector Stack Dictionary Deprecated Dokumentation af legacy collection classes Men hvorfor er de forældede? Legacy kollektioner har to store ulemper: 
 
 
 Alle interaktionspunkter med disse klasser synkroniseres. Klasserne har ingen fælles grænseflader og kræver en individuel tilgang. Lad os gå i orden. Den første ulempe er**, at alle interaktionspunkter med disse klasser er synkroniserede.** Men det føles mere som en fordel end det modsatte. Når alt kommer til alt, er sikker multithreading altid en god ting. Men hvad hvis disse samlinger bruges i en enkeltstrenget sammenhæng? Synkronisering reducerer simpelthen ydeevnen uden at give nogen reelle sikkerhedsmæssige fordele. Den anden ulempe** er, at klasser ikke har fælles grænseflader og kræver en individuel tilgang.** Dette fører til et problem, der er så gammelt som selve programmeringen: ikke-universel kode. Forestil dig bare, at vi er en udvikler, der arbejder på en gammel Java-version, og vi har kode bundet til For eksempel, her er en: Stack Stack<Integer> stack = new Stack<>();

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

System.out.println(stack.pop());
 Lige nu er koden uden noget hitch, men forestil dig, at den har ballonet til 1.000 linjer med 150 henvisninger til af variable. stack Så en dag sendte kunderne en fax til os og sagde, at de arbejdede meget langsomt (koden blokke, ikke kunderne). indeholder en matrix til lagring af elementer, og denne matrix genskabes for ofte. Stack Vi overvejer og fremsætter en teori: den linkede liste kan hjælpe med at øge app-præstationen med 100 gange! på internettet – og derefter rulle vores ærmer op for at kopiere og refaktere alle 150 referencer til Ikke i det hele taget, men vi ser ingen anden vej ud. LinkedList stack Lad os gå videre til nutiden, hvor vores kode ser sådan ud: Deque<Integer> deque = new ArrayDeque<>();
IntStream.range(0, 5)
        .forEach(deque::addLast);
System.out.println(deque.pollLast());
 Med tiden vokser koden også til at omfatte 150 referencer, men nu har den referencer til Vi følger den samme vej og fremsætter også teorien om, at det vil være hurtigere med en linket liste. To af som også gennemfører Og det er det eneste, der skal til! deque ArrayDeque LinkedList Deque Det er præcis, hvordan den løst problemet med manglende fælles grænseflader. Det hjælper med at undgå at være bundet til specifikke implementeringer. Og kan bruge den Interface i stedet. Samlinger rammer Vector List Afslutning På et tidspunkt, (Det er ) syntes som en fremragende idé: en metode, der ville blive kaldt, når et objekt blev ødelagt, frigivelse af systemressourcer. Finalisterne #finalize() Men i praksis var denne idé ikke så strålende: 
 
 
 
 
 finalisatoren kan ikke kaldes overhovedet, hvis der stadig var en henvisning til objektet et eller andet sted, eller hvis skraldesamleren ikke ønskede at slette det. hvis skraldekollektoren ønskede at ødelægge objektet, måtte det stadig vente, indtil denne kode blev udført; objektet kunne endda genoplive sig selv; Det værste er, at finishererne skabte perfekte betingelser for hukommelsestab. Moderne Java er meget fleksibel; selv skraldesamleren kan være af enhver art og konfigureres på forskellige måder. Og glem ikke, at skraldesamleren er garanteret ikke at indsamle en instans, så længe den har mindst én stærk reference. Af disse grunde bør logikken med at frigive systemressourcer ikke afhænge af objektets livscyklus. Hvis vi ser på dokumentationen for metode, vi ser, at det anbefales at bruge den interface i stedet. Det blev skabt specifikt til effektivt at frigive ressourcer uden at involvere skraldesamleren. at gøre det. #finalize() AutoCloseable Ikke at glemme Hvad angår sporing, når et objekt rent faktisk slettes, giver Java et alternativ: som løser de problemer, der er beskrevet ovenfor. java.lang.ref.Cleaner For klarhed, lad os spille rundt med Java hukommelse og skrive nogle usikre kode ved hjælp af en finisher: class ImmortalObject {  
    private static Collection<ImmortalObject> triedToDelete = new ArrayList<>();

    @Override  
    protected void finalize() throws Throwable {
        triedToDelete.add(this);
    }  
}
 Her genopretter vi bogstaveligt talt hvert tilfælde af at skraldespanden er ved at blive slettet, hvilket ikke vil behage din RAM eller dig selv, når den kolliderer med en . ImmortalObject OutOfMemoryError Sådan ser den tilsvarende kode ud med : Cleaner static List<ImmortalObject> immortalObjects = new ArrayList<>();

....

var immortalObject = new ImmortalObject();  
Cleaner.create()  
        .register(  
                immortalObject,  
                () -> immortalObjects.add(immortalObject)  
        );
 Det er værd at nævne, at vi også kan lytte til sletningen af absolut ethvert eksisterende objekt. Stop! Har vi lige lært, hvorfor denne tilgang er problematisk? Det er sandt, men det er kun dårligt med ressourceforvaltning. Nogle gange har en Java-applikation stadig brug for at vide, at skraldesamleren sletter et objekt. Klassen lever stadig op til sit navn, men ikke fordi vi tilføjer den til en statisk liste, når vi sletter instansen. Det er som om, at høreren har en henvisning til Nu vil objektet ikke blive genoplivet, fordi skraldesamleren ikke vil slette instansen. Det er mere idiomatisk i Java og ingen nekromancy er involveret. Runnable immortalObject Finalizers blev ofte brugt, når man arbejdede med objekter, der blev skabt via JNI et eller andet sted uden for Java-koden, for eksempel i C++. Men mekanismen var usikker, og finalers blev til sidst erstattet med et langt mere elegant alternativ. Nashornskribent Få husker, at Java engang bogstaveligt talt holdt tempoet med JavaScript: JDK 8 havde den indbyggede JS-motor, som giver udviklere mulighed for at køre JS-kode direkte fra Java. Nashorn Vi kunne implementere det meget populære banan puslespil uden at forlade Java: new NashornScriptEngineFactory()
        .getScriptEngine()
        .eval("('b' + 'a' + + 'a' + 'a').toLowerCase();");
 Faktisk er det en cool ting, men kun indtil vi indser, at Java-udviklere skal vedligeholde JavaScript-motoren. Nashorn kunne ikke holde trit med den hurtige udvikling af JavaScript, såvel som polyglotløsninger dukkede op, som GraalVM Polyglot. Disse faktorer førte til, at motoren blev forældet efter kun fire sprogversioner (i Java 11), og efter et stykke tid, det var endelig af Java 15. Kastet overbord Mens Nashorn har implementeret JavaScript på toppen af Java, skaber Polyglot en hel JVM-baseret platform, der understøtter flere sprog, herunder Java og JavaScript. Sikkerhedschef Mød en anden gammel timer, der overlevede indtil Java 17. . SecurityManager I dagene med vilde applets, hvor Java-kode kunne udføres direkte i browseren, Det er grundlaget for Java applikationssikkerhed. SecurityManager 
 
 Et applet er et lille program, der kører direkte i en browser og kan vise animationer, grafik eller interaktive elementer, men fungerer under strenge begrænsninger. Et applet er et lille program, der kører direkte i en browser og kan vise animationer, grafik eller interaktive elementer, men fungerer under strenge begrænsninger. Tiden er gået, vilde til sidst migreret fra browsere til skriveborde, og derefter døde helt ud som en løsning. Det har været og bliver ofte brugt i erhvervslivet. Applets SecurityManager af Men intet varer evigt, og Grim Reaper kom for Java 17 fjernet hele sit interiør og efterlod kun facaden uden nogen logik. Vi kan kun finde den pårørende: SecurityManager SecurityManager @Deprecated(since = "17", forRemoval = true)
public static void setSecurityManager(SecurityManager sm) {
    throw new UnsupportedOperationException(
             "Setting a Security Manager is not supported");
}
 Indtast fuldskærmstilstand Udtast fuldskærmstilstand Hvordan gjorde Det fungerede som en intern JVM-vagt, der intercepterede potentielt farlige operationer og kontrollerede, om hvert stakkeelement havde ret til at udføre en sådan handling. SecurityManager Hvad præcis gjorde Listen er enorm, så jeg foreslår, at vi bare kigger på de vigtigste punkter: SecurityManager 
 
 
 
 
 
 adgang til filsystemet; netværk af forbindelser; oprettelse og afslutning af processer, adgang til systemegenskaber; manipulation med klasser og refleksion. Det fungerede godt i dagene for browser applets, hvor det var nødvendigt at holde upålidelige kode i en sandkasse, men med udviklingen af containerisering blev det forældet. SecurityManager Selvom Den blev oprindeligt skabt til applets, men blev også brugt i andre sammenhænge. i vores PVS-Studio statiske analysator, det hjalp med at løse et sjovt problem: hvis den statiske klasse initializer i den analyserede kode kaldes Analyseprocessen vil blive afsluttet. Det gjorde det muligt for os at blokere sådanne operationer, når vi analyserede statiske felter, og noget vi senere erstattede med ASM. SecurityManager Støttet System#exit SecurityManager Forresten, selv om applets som en tilgang blev afbrudt tidligere end De er kun lige begyndt at blive fjernet fra JDK. SecurityManager Verden ændrer sig, tilgange ændrer sig, og Den går væk. SecurityManager Usikre Java fjerner usikkerhed. bogstaveligt talt. Måske den mest legendariske beboer af denne grav var . sun.misc.Unsafe Denne klasse var en hemmelig gateway ind i JVM dybder, hvor de sædvanlige sprogregler ikke længere var i kraft. Du kan nemt installere en Java-applikation . Unsafe SIGSEGV Hvordan? for eksempel sådan her: 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)
 I den område (1), vi har sat 2) I stedet for og prøv at udtrykke værdien til  (3). value Long.MAX_VALUE Object System.out Den virtuelle maskine er ikke glad for dette trick, og det styrter på den sidste linje, fordi indeholder affald i stedet for en reel reference til objektet, og dette er blot et eksempel på en sådan let at finde fejl. value Men hvorfor blev en så farlig mekanisme tilføjet til Java? Han blev ikke født som en anarkist, men som en frelser. og (vi vil tale om dem senere), de standard biblioteker måtte udføre lav-niveau operationer som hukommelseshåndtering, atomiske operationer, eller tråd blokering effektivt. Unsafe VarHandle MemorySegment Men hvordan kan vi gøre alt det ovenstående, hvis sproget forbyder dig at se under kappen? Det fremstod som en til Java’s egne behov. Unsafe internal Udviklerne havde til hensigt at bruge det kun inden for Java – og det havde endda beskyttelse mod at få ekstern adgang til sin instans. Se den magi, der fanger en "usikkerhed" på en usikker måde: Unsafe var Unsafe_theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
Unsafe_theUnsafe.setAccessible(true);
Unsafe unsafe = (Unsafe) Unsafe_theUnsafe.get(null);
 Dette objekt giver os mulighed for at torturere den virtuelle maskine så meget som vi ønsker. Men skynd dig ikke at kritisere de udviklere, der turde nå for, hvad Java forsøgte så hårdt at skjule for dem; det er værd at huske: adgangen til har hjulpet mange biblioteker til at blive mere effektive. For eksempel blev det populære Netty-bibliotek til at arbejde med netværk tvunget til at bruge Og når en udskiftning kom ud, Netty til det. Unsafe Unsafe Skiftede Hvilken slags erstatning taler vi om? Der er ikke én, men to: 
 
 
 Foreign Function & Memory API erstatter hukommelsesoperationer. VarHandle API erstatter atomære operationer. Disse API'er er ikke begrænset til blot at erstatte visse metoder i De er kraftfulde værktøjer til at arbejde sikkert med lavt niveau operationer. For eksempel, den udenlandske funktion & hukommelse API giver dig mulighed for at kalde indfødte funktioner uden at bruge den besværlige JNI! Unsafe Java's usikkerhed forsvinder langsomt til glemsomhed, efterlader nye, veldesignede og kraftfulde API'er, der gør det samme uden frygt for de betingede . SIGSEGV Hvorfor er graven fyldt op? Java vokser op, smider forældede ideer væk, bliver sikrere, renere og enklere. Hver ny API er ikke bare "tilføje et andet modul", men lukke gamle huller på en mere sofistikeret måde. Samtidig spiller den virtuelle "tomb" en vigtig kulturel rolle: den registrerer udviklingen af ideer og beslutninger, minder os om den vej, vi har rejst og danner den kontekst, der er nødvendig for den meningsfulde platformudvikling.

Read My Stories

Denne lyd er produceret på historiens originalsprog!

Java's Growing Graveyard: De gamle API'er, der bliver begravet - og hvad der erstattede dem

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet Google Cloud: HackerNoon Company of the Week

Meet Bybit: HackerNoon Company of the Week

Meet Octopus Network: HackerNoon Company of the Week

Meet Sentry: HackerNoon Company of the Week

Meet Google Cloud: HackerNoon Company of the Week

Meet Bybit: HackerNoon Company of the Week

Meet Octopus Network: HackerNoon Company of the Week

Meet Sentry: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps