JAVA 13 i 14. Co zmienia się w nowych wersjach?

Najnowsze wersje Javy ukazały się odpowiednio we wrześniu 2019 r. (Java 13) i sześć miesięcy później w marcu (Java 14). Opiszemy je po kolei, aby zobaczyć zmiany, które zaszły na przestrzeni czasu.

JAVA 13

Oprócz ponad 2300 poprawek błędów i drobnych ulepszeń, nowa wersja Java zawiera 5 głównych ulepszeń, które są również nazywane JEP-ami. Java 13 wprowadza usprawnienia w zakresie usuwania pamięci, udostępniania danych klas aplikacji i bloków tekstowych.

Wprowadzenie bloków tekstowych

Główną nową funkcją Javy 13 dla programistów jest wprowadzenie bloków tekstowych. Ponownie, architekci odpowiedzialni za ewolucję Javy postanowili zachować ostrożność, ponieważ bloki tekstowe są dostępne tylko jako funkcja eksperymentalna w Javie 13.

Bloki tekstowe to po prostu nowy typ literału łańcuchowego, który pozwala pisać łańcuchy w wielu wierszach. Aby uprościć ich użycie, zdecydowano, że blok tekstowy będzie rozpoczynał się od nowego, określonego separatora i znaku końca wiersza. Pozwala to na użycie prostych cudzysłowów w bloku tekstowym bez ich ucieczki.

Bloki tekstowe zachowują zdefiniowane przez użytkownika wcięcia, gdy są deklarowane w kodzie źródłowym. Usuwane jest tylko wcięcie wykonane przed pierwszą literą, ponieważ jest ono uważane za losowe.

Ulepszenia w Garbage Collectorze

Garbage Collector jest istotną częścią wirtualnych maszyn Java. Wraz z rozwojem JDK, aby sprostać nowym potrzebom aplikacji Java, Oracle i Red Hat zaproponowały nowe implementacje.

W ten sposób w Javie 11 pojawił się niskopoziomowy Garbage Collector o nazwie ZGC. Ten Garbage Collector był oferowany eksperymentalnie i nie był dostępny dla wszystkich środowisk.

W Javie 13 ZGC został ulepszony, aby umożliwić zwracanie nieużywanego stosu pamięci do bazowego systemu operacyjnego. Obecnie ZGC tego nie robi, a to zachowanie wyraźnie nie było optymalne dla wszystkich typów aplikacji i środowisk docelowych. Było to jeszcze bardziej problematyczne w przypadkach, gdy wykorzystanie pamięci jest poważnym problemem. Na przykład:

• Środowiska kontenerowe.

• Środowiska, w których aplikacja może być wyłączona przez długi czas i może konkurować z innymi aplikacjami o zasoby.

• Aplikacja, której wymagania dotyczące miejsca na dysku mogą zmieniać się podczas działania.

Inne garbage collectory, takie jak G1 lub Shenandoah firmy Red Hat, zapewniają obecnie tę możliwość. Konieczne było zatem dodanie tej możliwości do ZGC w Javie 13, aby ułatwić jego przyszłe wdrożenie.

API Gniazd

Ponowna implementacja starszego API Gniazd, która zastępuje podstawową implementację używaną przez API gniazd, nowocześniejszą implementacją, łatwą do debugowania i utrzymania. Nowa implementacja zostanie dostosowana do pracy z wątkami trybu użytkownika, znanymi również jako włókna. Starsze wspomniane API pochodzą z JDK 1.0 i są mieszanką starszego kodu C i Java, opisywanego jako trudny do debugowania i utrzymania. Starsza implementacja ma również inne problemy, takie jak natywna struktura danych do obsługi asynchronicznego wyłączania, co powoduje problemy z niezawodnością i przenośnością, oraz problemy z współbieżnością, które muszą zostać poddane przeglądowi.

Dynamiczne Archiwa CDS

Wiele wydarzyło się w wirtualnej maszynie Java (JVM) i bibliotece klas. Class Data Sharing (CDS) zostało wprowadzone w Javie 5. Celem CDS jest skrócenie czasu uruchamiania aplikacji Java poprzez przechowywanie niektórych informacji o klasach w archiwach Class Data Sharing. Dane te mogą być następnie ładowane w czasie wykonywania i używane przez kilka JVM.

Jednak do Javy 10, współdzielone archiwa były dostępne tylko dla ładowarki modułów klasy Bootstrap. Począwszy od Javy 10, CDS zostało rozszerzone na Application Class Data Sharing (AppCDS). AppCDS umożliwia wbudowanym systemom i platformowym ładowarkom klas, a także zdefiniowanym przez użytkownika ładowarkom klas, dostęp do archiwów CDS. Listy klas są wymagane do tworzenia archiwów CDS w celu identyfikacji klas do załadowania.

Wcześniej te listy klas musiały być określane przez testowe uruchomienia aplikacji, aby ustalić, które klasy zostały faktycznie załadowane podczas wykonania. Od Javy 12, domyślne archiwa CDS są dostarczane z JDK, które są oparte na liście klas JDK. Celem jest zaoszczędzenie dodatkowych testowych uruchomień aplikacji. Po wykonaniu aplikacji archiwizowane są tylko nowo załadowane klasy aplikacji i biblioteki, które nie są jeszcze w CDS domyślnej warstwy, dynamiczne archiwowanie jest aktywowane poprzez linię poleceń.

Wyrażenia switch

Jest to aktualizacja, która wprowadziła nowe wyrażenia switch w JDK 12 jako funkcję podglądu języka. Dodano nową, uproszczoną formę bloku switch z etykietami. Po wprowadzeniu nowej składni w JDK 12, wysłano prośbę o opinię na listę mailingową. Zebrane opinie zaowocowały badaniem, które wprowadza tylko jedną zmianę. W nowej wersji wyrażeń switch, zostanie ona zastąpiona nową instrukcją yield. Nowe wyrażenia Switch są nadal dostępne tylko w trybie podglądu. Java 13 nie ma wielu JEP-ów. Dla większości użytkowników Javy interesujące będą tylko bloki tekstowe i wyrażenia Switch. Jednak są to tylko funkcje języka podglądu, które nie są dostępne domyślnie.

JAVA 14

Java 14 dodaje nowe funkcje, aby poprawić produktywność programistów, w tym wsparcie Java dla wyrażeń Switch, nowe API do ciągłego monitorowania danych JDK Flight Recorder oraz zwiększoną dostępność niskopoziomowego Z Garbage Collector dla macOS i Windows.

JDK 14 przynosi wiele nowych funkcji do języka programowania Java. Niektóre z nich są bardziej interesujące niż inne, a niektóre są bardziej jak porządkowanie. Oto podsumowanie nowych funkcji:

Dopasowanie wzorców dla instanceof

Jest to funkcja podglądu w JDK 14. Dopasowanie wzorców pozwala na bardziej zwięzłe i bezpieczniejsze przedstawienie typowej logiki programu, głównie warunkowego wyodrębniania komponentów z obiektów. Kod może być krótki i bezpieczny dla typów.

Alokacja pamięci w tym NUMA dla G1

Alokacja pamięci NUMA dla modułu Garbage Collector G1 ma na celu poprawę wydajności G1 na dużych maszynach.

Strumieniowanie zdarzeń JFR

Strumieniowanie zdarzeń JFR zapewnia API do ciągłego wykorzystywania danych JFR zarówno z aplikacji w procesie, jak i poza procesem. JFR to narzędzie do zbierania profili i diagnostycznych danych dotyczących uruchomionych aplikacji Java i maszyny wirtualnej Java. Propozycja strumieniowania zdarzeń rejestruje ten sam zestaw zdarzeń, co w przypadku braku strumieniowania, z narzutem mniejszym niż jeden procent, jeśli to możliwe. Strumieniowanie zdarzeń musi współistnieć z nagraniami niestrumieniowymi, zarówno na dysku, jak i w pamięci.

MappedByteBuffer

MappedByteBuffer z możliwością rozszerzenia dostępu do pamięci nieulotnej (NVM). Ta pamięć jest używana do trwałego przechowywania danych. Ta propozycja ulepszeń Java wprowadza nowy moduł i klasę do API JDK.

NullPointerExceptions

Ulepszenie NullPointerExceptions dotyczy użyteczności wyjątków generowanych przez wirtualną maszynę Java. Ma to na celu dostarczenie przydatnych informacji programistom o przedwczesnym zakończeniu programu i poprawę zrozumienia programu poprzez wyraźniejsze powiązanie dynamicznego wyjątku ze statycznym kodem programu.

Records

JEP 359 udostępnia rekordy jako funkcję podglądu dla Javy. Rekordy to nowy typ. Reprezentują ograniczoną formę deklaracji klasy. Rekordy różnią się od klasycznych klas tym, że nie mogą oddzielić swojego API od swojej reprezentacji. Jednak utracona wolność jest rekompensowana zwiększoną precyzją.

Wyrażenia Switch

W JEP 325 zaproponowano rozszerzenie instrukcji switch tak, aby mogła być używana jako instrukcja lub wyrażenie. Obie formy powinny być w stanie używać „tradycyjnych” lub „uproszczonych” zmiennych i struktur kontrolnych. Celem tego JEP-a było uproszczenie codziennego programowania i utorowanie drogi do dopasowywania wzorców w połączeniu z instrukcją Switch.

Usunięcie portów Solaris i SPARC

System operacyjny Solaris nie jest już tak naprawdę aktualny. W związku z tym chęć Oracle do oznaczenia portów dla Solaris / SPARC, Solaris / x64 i Linux / SPARC jako przestarzałych nie jest zaskoczeniem. Należy jednak zauważyć, że stare wersje Javy (do JDK 14) powinny działać bez zmian na starych systemach, włączając w to odpowiednie porty. Celem tego wszystkiego jest zajęcie się innymi funkcjami.

Usunięcie modułu CMS (Concurrent Mark Sweep)

Usunięcie Garbage Collector Concurrent Mark Sweep (CMS), który był wcześniej zbędny i przeznaczony do usunięcia. Powstały następcy CMS, w tym ZGC i Shenandoah.

Z Garbage Collector na macOS i Windows

Propozycja ma na celu udostępnienie Z Garbage Collector jako opcji dla użytkowników macOS i Windows. Istnieje również funkcjonalność kolektora do zwolnienia nieużywanej pamięci dla systemu.

Wycofanie wywołania ParallelScavenge + SerialOld

JEP 366 dotyczy również garbage collectorów, a w tym przypadku kombinacji dwóch: ParallelScavenge i SerialOld. Sugeruje się oznaczenie kombinacji tych dwóch algorytmów jako przestarzałych, ponieważ prawdopodobnie tylko niewielu programistów używa ich w tej konstelacji.

Usunięcie narzędzia Pack 200

Pack200 to schemat kompresji plików JAR. Usunięto narzędzia i API Pack200. Wszystkie zostały wycofane w Java SE 11 z zamiarem ich usunięcia w przyszłości.

Bloki tekstowe

Druga wersja podglądu bloków tekstowych, wieloliniowy literał ciągu, który unika większości specjalnych sekwencji i automatycznie formatuje ciąg w przewidywalny sposób.

Foreign Memory Access API

Istnieją tysiące bibliotek i aplikacji Java, które uzyskują dostęp do pamięci zewnętrznej. Jednak samo API Java nie zapewnia dobrego sposobu na to, chociaż może obniżyć koszty czyszczenia i współdzielić pamięć między wieloma procesami.

Java 14 przynosi wiele nowości. Wprowadzono w niej kilka interesujących zmian, jednak warto zaznaczyć, że nie są to zmiany przełomowe. Jednak, podobnie jak w poprzednich edycjach, widoczny jest trend stopniowej modernizacji języka. Stale otrzymujemy ulepszenia Garbage Collectors, które są kluczowe dla wydajności aplikacji maszyn wirtualnych Java.