Nieuwe Java 13-functies

1. Overzicht

In september 2019 werd JDK 13 uitgebracht, volgens Java's nieuwe release-cadans van zes maanden. In dit artikel zullen we de nieuwe functies en verbeteringen bekijken die in deze versie zijn geïntroduceerd.

2. Preview Developer Features

Java 13 heeft twee nieuwe taalfuncties toegevoegd, zij het in de voorbeeldmodus. Dit houdt in dat deze functies volledig zijn geïmplementeerd zodat ontwikkelaars ze kunnen evalueren, maar dat ze nog niet productieklaar zijn. Ze kunnen ook worden verwijderd of permanent worden gemaakt in toekomstige releases op basis van feedback.

We moeten specificeren -Voorbeeld inschakelen als een opdrachtregelvlag om de preview-functies te gebruiken. Laten we ze eens diepgaand bekijken.

2.1. Switch Expressions (JEP 354)

We zagen aanvankelijk switch-expressies in JDK 12. Java 13's schakelaar expressies bouwen voort op de vorige versie door een nieuw opbrengst uitspraak.

Gebruik makend van opbrengst, kunnen we nu effectief waarden retourneren van een switch-expressie:

@Test @SuppressWarnings ("preview") public void whenSwitchingOnOperationSquareMe_thenWillReturnSquare () {var me = 4; var operation = "squareMe"; var result = switch (operatie) {case "doubleMe" -> {geef mij * 2; } case "squareMe" -> {geef mij * mij; } default -> me; }; assertEquals (16, resultaat); }

Zoals we kunnen zien, is het nu eenvoudig om het strategiepatroon te implementeren met behulp van het nieuwe schakelaar.

2.2. Tekstblokken (JEP 355)

De tweede preview-functie zijn tekstblokken voor meerdere regels Draads zoals embedded JSON, XML, HTML, etc.

Om JSON eerder in onze code in te sluiten, verklaarden we het als een Draad letterlijk:

String JSON_STRING = "{\ r \ n" + "\" name \ ": \" Baeldung \ ", \ r \ n" + "\" website \ ": \" // www.% S.com / \ " \ r \ n "+"} ";

Laten we nu dezelfde JSON schrijven met Draad tekstblokken:

String TEXT_BLOCK_JSON = "" "{" name ":" Baeldung "," website ":" //www.%s.com/ "}" "";

Zoals duidelijk is, is het niet nodig om aan dubbele aanhalingstekens te ontsnappen of een regelterugloop toe te voegen. Door tekstblokken te gebruiken, is de ingesloten JSON veel eenvoudiger te schrijven en gemakkelijker te lezen en te onderhouden.

Bovendien allemaal Draad functies zijn beschikbaar:

@Test openbare leegte whenTextBlocks_thenStringOperationsWorkSame () {assertThat (TEXT_BLOCK_JSON.contains ("Baeldung")). IsTrue (); assertThat (TEXT_BLOCK_JSON.indexOf ("www")). isGreaterThan (0); assertThat (TEXT_BLOCK_JSON.length ()). isGreaterThan (0); } 

Ook, java.lang.String heeft nu drie nieuwe methoden om tekstblokken te manipuleren:

  • stripIndent () - bootst de compiler na om incidentele witruimte te verwijderen
  • translateEscapes () - vertaalt ontsnappingssequenties zoals "\ t" naar "\ T"
  • opgemaakt () - werkt hetzelfde als String :: formaat, maar voor tekstblokken

Laten we een korte blik werpen op een String :: geformatteerd voorbeeld:

assertThat (TEXT_BLOCK_JSON.formatted ("baeldung"). bevat ("www.baeldung.com")). isTrue (); assertThat (String.format (JSON_STRING, "baeldung"). bevat ("www.baeldung.com")). isTrue (); 

Omdat tekstblokken een voorbeeldfunctie zijn en in een toekomstige release kunnen worden verwijderd, zijn deze nieuwe methoden gemarkeerd voor veroudering.

3. Dynamische CDS-archieven (350 JEP)

Class data sharing (CDS) is al een tijdje een prominent kenmerk van Java HotSpot VM. Het staat toe klasse-metagegevens die over verschillende JVM's moeten worden gedeeld om de opstarttijd en het geheugengebruik te verminderen. JDK 10 breidde deze mogelijkheid uit door applicatie-CDS (AppCDS) toe te voegen - om ontwikkelaars de mogelijkheid te geven applicatieklassen op te nemen in het gedeelde archief. JDK 12 heeft deze functie verder verbeterd en standaard CDS-archieven toegevoegd.

Het archiveren van applicatieklassen was echter vervelend. Om archiefbestanden te genereren, moesten ontwikkelaars hun applicaties uitproberen om eerst een klassenlijst te maken en deze vervolgens in een archief te dumpen. Daarna zou dit archief kunnen worden gebruikt om metadata tussen JVM's te delen.

Met dynamische archivering heeft JDK 13 dit proces vereenvoudigd. Nu we kunnen een gedeeld archief genereren op het moment dat de toepassing wordt afgesloten. Dit heeft de noodzaak van proefritten geëlimineerd.

Om applicaties in staat te stellen een dynamisch gedeeld archief te maken bovenop het standaardsysteemarchief, moeten we een optie toevoegen -XX: ArchiveClassesAtExit en specificeer de archiefnaam als argument:

java -XX: ArchiveClassesAtExit = -cp AppName

We kunnen dan het nieuw gemaakte archief gebruiken om dezelfde app uit te voeren -XX: SharedArchiveFile keuze:

java -XX: SharedArchiveFile = -cp AppName

4. ZGC: Uncommit Unused Memory (JEP 351)

De Z Garbage Collector werd in Java 11 geïntroduceerd als een garbagecollection-mechanisme met lage latentie, zodat GC-pauzetijden nooit langer waren dan 10 ms. In tegenstelling tot andere HotSpot VM GC's zoals G1 en Shenandoah, was het echter niet uitgerust om ongebruikt heap-geheugen terug te sturen naar het besturingssysteem. Java 13 heeft deze mogelijkheid toegevoegd aan de ZGC.

We krijgen nu een kleinere geheugenvoetafdruk en prestatieverbetering.

Beginnend met Java 13, de ZGC retourneert nu standaard niet-toegewezen geheugen naar het besturingssysteem, totdat de opgegeven minimale heapgrootte is bereikt. Als we deze functie niet willen gebruiken, kunnen we teruggaan naar de Java 11-manier door:

  • Met behulp van optie -XX: -ZUncommit, of
  • Gelijk minimum instellen (-Xms) en maximum (-Xmx) stapelgroottes

Bovendien heeft ZGC nu een maximale ondersteunde heapgrootte van 16 TB. Eerder was 4TB de limiet.

5. Implementeer de Legacy Socket API (JEP 353) opnieuw

We hebben Socket (java.net.Socket en java.net.ServerSocket) API's als een integraal onderdeel van Java sinds het begin. Ze zijn de afgelopen twintig jaar echter nooit gemoderniseerd. Ze waren geschreven in het oude Java en C, waren omslachtig en moeilijk te onderhouden.

Java 13 ging tegen deze trend in en verving de onderliggende implementatie om de API af te stemmen op de futuristische threads in de gebruikersmodus. In plaats van PlainSocketImpl, verwijst de providerinterface nu naar NioSocketImpl. Deze nieuw gecodeerde implementatie is gebaseerd op dezelfde interne infrastructuur als java.nio.

Nogmaals, we hebben een manier om terug te gaan naar het gebruik PlainSocketImpl. We kunnen de JVM starten met de systeemeigenschap -Djdk.net.usePlainSocketImpl ingesteld als waar om de oudere implementatie te gebruiken. De standaardwaarde is NioSocketImpl.

6. Diverse wijzigingen

Afgezien van de hierboven genoemde JEP's, heeft Java 13 ons nog een paar opmerkelijke veranderingen gegeven:

  • java.nio - methode FileSystems.newFileSystem (pad, kaart) toegevoegd
  • java.time - nieuwe officiële naam van het Japanse tijdperk toegevoegd
  • javax.crypto - ondersteuning voor MS Cryptography Next Generation (CNG)
  • javax.security - eigendom jdk.sasl.disabled Mechanisms toegevoegd om SASL-mechanismen uit te schakelen
  • javax.xml.crypto - nieuw Draad constanten die zijn geïntroduceerd om Canonical XML 1.1 URI's te vertegenwoordigen
  • javax.xml.parsers - nieuwe methoden toegevoegd om DOM- en SAX-fabrieken te instantiëren met naamruimtenondersteuning
  • Unicode-ondersteuning geüpgraded naar versie 12.1
  • Ondersteuning toegevoegd voor canonicalisatie van Kerberos-hoofdnamen en verwijzingen tussen domeinen

Bovendien worden enkele API's voorgesteld om te verwijderen. Deze omvatten de drie Draad hierboven genoemde methoden, en de javax.security.cert API.

Tot de verhuizingen behoren de rmic tool en oude functies van de JavaDoc-tool. Pre-JDK 1.4 SocketImpl implementaties worden ook niet langer ondersteund.

7. Conclusie

In dit artikel zagen we alle vijf JDK Enhancement Proposals geïmplementeerd door Java 13. We hebben ook enkele andere opmerkelijke toevoegingen en verwijderingen opgesomd.

Zoals gewoonlijk is de broncode beschikbaar op GitHub.


$config[zx-auto] not found$config[zx-overlay] not found