Java 14 już za nami. Równo 15 września zostanie udostępniona nowa wersja JDK 15. Zmiany w Garbage Collector, Text Blocks, Hidden Classes, Shenandoah, to tylko kilka z ciekawszych zmian. Szczegóły w artykule.
Hidden Classes
Klasy ukryte to jedna z ciekawszych zmian, jakie wprowadza JDK 15. Dzięki tej zmianie jesteśmy w stanie ukryć szczegóły implementacyjne frameworków. Klasy przestają być dostępne w kodzie bajtowym dla innych klas. Nie można się do nich dostać poprzez mechanizm refleksji. Ale co to oznacza w praktyce?
Sporo frameworków podczas pracy aplikacji (runtime) tworzy różne wewnętrzne klasy, które są następnie wykorzystywane poprzez mechanizm refleksji. Twórcy Javy zauważyli, że powoduje to kilka nieścisłości.
- Cykl życia takiej klasy jest dłuższy, niż wynika to z potrzeby użycia klasy.
- Klasa, poprzez mechanizm refleksji jest widoczna dla innych klas.
Wprowadzenie Hidden Classes pozwoli na ukrycie takich klas we frameworkach (również ukrycie przed mechanizmami zewnętrznych refleksji). Dzięki takiemu podejściu będzie możliwa bardziej agresywna praca odśmiecacza pamięci – Garbage Collectora.
Piguła wiedzy o najlepszych praktykach testowania w Java
Pobierz za darmo książkę 100 stron o technikach testowania w Java
Text Blocks
To zmiana długo wyczekiwana przez developerów. Dzięki wprowadzeniu bloków tekstowych unikniemy dodawania znaków końca linii, przez co kod stanie się dużo czytelniejszy. Zilustrujmy to przykładem. W pierwszej kolejności zaprezentuje, jak może wyglądać blok tekstu aktualnie.
String html = "<html>\n" +
" <body>\n" +
" <p>Hello, world - without Text Blocks</p>\n" +
" </body>\n" +
"</html>\n";
A teraz zobaczmy jak ten sam kod może wyglądać w Java 15.
String html = """
<html>
<body>
<p>Hello, world - with Text Blocks</p>
</body>
</html>
""";
Warto jest dodać, że bloki tekstowe z powodzeniem będą mogły być stosowane w XML, SQL czy JSON.
Sealed Classes
Zmiana, która pozwoli nam kontrolować, które klasy lub interfejsy będą rozszerzać naszą klasę, lub interfejs, opisaną słowem kluczowym sealed. Programista, będzie miał większą kontrolę nad kodem. Wraz ze zmianą doszło kilka nowych słów kluczowych.
- sealde– oznacza klasę lub interfejs, powoduje taką samą widoczność jak wcześniej, ale ogranicza dziedziczenie klas czy rozszerzanie interfejsów
package pl.softwareskill.geometry;
public sealed class Shape {
...
}
- permits – pozwala klasom na dziedziczenie wybranych klas, pomimo oznaczenia sealed
package pl.softwareskill.geometry;
public sealed class Shape
permits Circle, Rectangle, Square {...}
- non-sealed – umożliwia odwrócenie tego, co wprowadził modyfikator sealed. Klasa, która może dziedziczyć z klasy sealed, po wprowadzeniu tego modyfikatora, pozwala na dalsze dziedziczenie z siebie bez restrykcji wprowadzonych przez klasę sealed.
package pl.softwareskill.geometry;
public non-sealed class Square extends Shape {...}
Remove the Nashorn JavaScript Engine
W Java 8 zadebiutował projekt Nashorn umożliwiający uruchamianie kodu JavaScript przy wykorzystaniu natywnej JVM. Jako że język JavaScript ostatnimi laty rozwijał się bardzo szybko, w JDK 11 silnik Nashorn oznaczone jako deprecated. Wersja JDK 15 całkowicie wycofuje silnik skryptowy JavaScript i interfejsy API Nashorn, ponieważ powodował on trudności w utrzymaniu.
Psst… Interesujący artykuł?
Jeżeli podoba Ci się ten artykuł i chcesz takich więcej – dołącz do newslettera. Nie ominą Cię materiały tego typu.
ZGC: A Scalable Low-Latency Garbage Collector
Garbage Collector ZGC został wprowadzony już w wersji JDK 11, jednak był on w wersji niestabilnej – do testów. Przez ten czas zdążył się „wygrzać” i w wersji JDK 15 ZGC wchodzi w wersji stabilnej, produkcyjnej. ZGC to Garbage Collector nastawiony na niską latencję. Oznacza to, że jest zoptymalizowany pod kątem krótkich pauz aplikacji – krótkiego czasu odśmiecania pamięci. W ramach ciekawostek można dodać, że docelowo czas pauzy GC nie będzie przekraczać 10ms – ambicje są na zejście do 1ms.
Shenandoah: A Low-Pause-Time Garbage Collector
Shenandoah to drugi Garbage Collector, mający podobne założenia jak ZGC (low latency) jednak opierający się na innych algorytmach. Został wprowadzony w JDK 12 – po wygrzaniu się dostał zielone światło i doczekał się wersji produkcyjnej w JDK 15.
Pattern Matching for instanceof
Jest to druga wersja. Ta pierwsza pojawiła się już w JDK 14. Dzięki tej zmianie, w bardziej płynny sposób będzie można używać zmiennych. Do tej pory typowym było:
if (obj instanceof String) {
String s = (String) obj;
System.out.println(s);
}
Teraz, powyższy kod możemy zapisać następująco:
if (obj instanceof String s) {
System.out.println(s);
}
Records
Podobnie jak Pattern Matching – rekordy zostały wprowadzone już w JDK 14. Bardzo cieszę się z tej zmiany – w JDK 15 mamy drugie preview, co daje szanse na to, że w JDK 16 zmiana zagości na stałe. Ale czym jest rekord w Javie?
Moim skromnym zdaniem, klasy w Javie, których celem jest reprezentowanie niezmiennych danych (ang. immutable data) są zbyt rozwlekłe. Można oczywiście użyć projektu Lombok, ale patrząc na inne języki programowania można dojść do wniosku, że obiekty immutable można uprościć na poziomie samej składni języka – bez użycia dodatkowych bibliotek. Spójrzmy na przykład, jak pisało się to do tej pory.
public final class Person {
private final String firstName;
private final String lastName;
private final int age;
public Person(String firstName, String lastName, int age) {
this.firstName = firstName;
this.lastName = lastName;
this.age = age;
}
public String firstName() {
return firstName;
}
public String lastName() {
return lastName;
}
public int age() {
return age;
}
@Override
public boolean equals(Object o) {
if (this == o) {
return true;
}
if (o == null || getClass() != o.getClass()) {
return false;
}
Person personOld = (Person) o;
return age == personOld.age &&
Objects.equals(firstName, personOld.firstName) &&
Objects.equals(lastName, personOld.lastName);
}
@Override
public int hashCode() {
return Objects.hash(firstName, lastName, age);
}
@Override
public String toString() {
final StringBuilder sb = new StringBuilder("Person{");
sb.append("firstName='").append(firstName).append('\'');
sb.append(", lastName='").append(lastName).append('\'');
sb.append(", age=").append(age);
sb.append('}');
return sb.toString();
}
}
Kod z użyciem biblioteki Lombok wyglądałby następująco:
@Value
public class Person {
String firstName;
String lastName;
int age;
}
Z kolei kod w JDK 15 może wyglądać w ten sposób:
record Person (String firstName, String lastName, int age) { }
Podsumowanie
Na pierwszy rzut oka lista zmian wprowadzonych do JDK 15 nie wydaje się tak bardzo rewolucyjna. Jednak diabeł tkwi w szczegółach. Po wczytaniu się w specyfikacje możemy dostrzec takie zmiany jak Text Blocks czy Record, które „upiększą” nasz kod. Podobnie sprawa ma się z nowymi Garbage Collectorami, których isteninia na co dzień nie zauważamy, a jednak mają ogromny wpływ na wydajność naszych aplikacji.
Jeśli przeczytałeś/aś ten artykuł i jeśli Ci się spodobał – będę bardzo wdzięczny, jeśli podzielisz się nim ze swoimi znajomymi i dołączysz do naszego fanpage na FaceBook – https://www.facebook.com/softwareskill
Tło zdjęcie utworzone przez jannoon028 – pl.freepik.com
Podoba Ci się ten artykuł? Weź więcej.
Jeżeli uważasz ten materiał za wartościowy i chcesz więcej treści tego typu – nie przegap ich i otrzymuj je prosto na swoją skrzynkę. Nawiążmy kontakt.
Gdybyś potrzebował jeszcze więcej:
Jesteś Java Developerem?
Przejdź na wyższy poziom wiedzy
„Droga do Seniora” 🔥💪
Jesteś Team Leaderem? Masz zespół?
Podnieś efektywność i wiedzę swojego zespołu 👌
Piguła wiedzy o najlepszych praktykach testowania w Java
Pobierz za darmo książkę 100 stron o technikach testowania w Java
