Adam Kukołowicz
Adam KukołowiczCo-founder @ Bulldogjob

Java 11 - nowa wersja już dostępna

Dowiedz się, jakie nowości oferuje Java 11 i czy warto zrobić upgrade. Czy licencja będzie płatna?
24.09.20186 min
Java 11 - nowa wersja już dostępna

Java 11 jest gotowa do zastosowań produkcyjnych. Warto migrować swój kod na nową wersję czy może lepiej się wstrzymać? Co w ogóle mi to da? Java 11 przestanie być darmowa? Tyle pytań, a czasu coraz mniej.

Skąd to poruszenie?

Po pierwsze - jest zamieszanie z licencjami.

Oracle kończy z wydawaniem Oracle JDK za darmo do użytku komercyjnego na początku 2019 (do użytku osobistego nadal będzie za free). Firma w ogóle nie wyda darmowego JDK 11 do zastosowań komercyjnych. Tak - jeśli chcesz mieć implementację Javy od Oracle, będziesz płacić. Co miesiąc 2.50 USD za użytkownika plus 25 USD za procesor w zastosowaniach serwerowych i chmurowych. Żeby było śmieszniej, liczba licencji na procesor to zaokrąglony do góry wynik mnożenia liczby rdzeni, na których działa program i współczynnika określonego dla danego procesora przez Oracle.

Na szczęście jest rozwiązanie tej sytuacji - OpenJDK wydawane na licencji GPL. Tej wersji może używać każdy bez opłat. Dodatkowo Oracle zobowiązało się, że od wersji 11 OpenJDK i Oracle JDK będą wymienne:

As announced in September 2017, with the OracleJDK and builds of Oracle OpenJDK being interchangeable for releases of Java SE 11 and later, the Oracle JDK will primarily be for commercial and support customers and OpenJDK builds from Oracle are for those who do not want commercial support or enterprise management tools.

Kolejną deklaracją jest wspieranie OpenJDK przez Oracle darmowymi aktualizacjami przez co najmniej sześć miesięcy od daty wydania. To już jest jakiś punkt zaczepienia, ale nie wiemy, co będzie dalej - być może Oracle przedłuży swoje wsparcie, być może zostawi projekt społeczności. Czas pokaże.

Po drugie Java 11 to LTS, czyli Long-term Support.

Oznacza to, że ta wersja będzie wspierana do września 2023, a przedłużone wsparcie potrwa aż do września 2026. To daje dobre podstawy do wyboru Javy 11 w długo utrzymywanych projektach. Podane daty obowiązują tylko dla komercyjnej wersji Javy. W przypadku OpenJDK wszystko będzie w rękach społeczności open source (i firm, którym zależy na wsparciu projektu). W „najgorszym” wypadku podbijanie wersji co pół roku stanie się standardem w świecie Javy. Kolejna wersja LTS to Java 17 planowana za trzy lata.

To wszystko nie oznacza, że musisz robić upgrade z Javy 8 już teraz. Co prawda Oracle kończy z udostępnianiem swojego JDK za darmo w styczniu 2019, ale licencja komercyjna gwarantuje rozwój tej wersji aż do marca 2022 i przedłużone wsparcie do marca 2025. To naprawdę dużo czasu. Więcej o dostępych opcjach znajdziesz w artykule "Czy to koniec Javy 8?".

Co technicznie przynosi Java 11?

Nowa Java to nie tylko kwestie formalne, ale też kilka ulepszeń. W sumie do tego wydania wchodzi 17 JEP-ów. Wiele z nich to naturalne przedłużenie pracy, którą widać od kilku poprzednich release’ów. Java ma być szybka, bardziej przyjazna programiście, ma pozbyć się zbędnych modułów i stawiać na dobre biblioteki standardowe, które pomogą walczyć ze spuchniętymi zależnościami.

Wyrzucenie tego, co niepotrzebne

W ramach pozbywania się tego, co zbędne, usunięto moduły Javy EE i CORBA (JEP 320). Obydwa były od wersji 9 oznaczone jako przestarzałe i przeznaczone do usunięcia. W obydwu przypadkach standardy ewoluowały niezależnie od Javy SE, co stwarzało coraz większe koszty utrzymania modułów. Z biegiem czasu te koszty zaczęły znacznie przeważać benefity.

Jako przestarzałe zostały oznaczone Nashorn JavaScript Engine (JEP 335) i Pack200 (JEP 336). Nashorn JavaScript Engine trafił do Javy niedawno, bo w wersji 8, ale przez szybki rozwój JS zespół przestał nadążać z rozwojem silnika. Ten JEP może zostać wycofany, jeżeli w najbliższym czasie sformuje się zespół, który przejąłby utrzymanie tej części projektu. Pack200 to metoda kompresji używana do plików JAR, której już mało kto używa, bo przesyłanie plików przy obecnej prędkości internetu to nie problem.

Możliwości profilowania

Do OpenJDK trafia Flight Recorder znany z Oracle JDK (JEP 328) - czyli framework pozwalający na zbieranie danych o działaniu aplikacji. Nowością jest profiler umożliwiający śledzenie alokacji na stercie (JEP 331) bardzo niskim kosztem - narzut wynikający ze stosowania go to tylko 1-3%. Nowe narzędzie będzie dostępne w JVMTI.

Nowe standardy

W Javie 11 znajdziemy implementacje:

  • TLS 1.3 (JEP 332), ale bez 0-RTT, Post-handshake authentication i Signed Certificate Timestamps
  • uzgadniania kluczy z wykorzystaniem krzywych eliptycznych Curve25519 i Curve448 (JEP 324)
  • algorytmów kryptograficznych ChaCha20 i Poly1305 (JEP 329).

Nowa wersja będzie też wspierać Unicode 10 (JEP 327).

Korzyści wydajnościowe

Dostępne są dwa nowe garbage collectory.

Pierwszy z nich - Epsilon (JEP 318) - to no-op, czyli taki, który w ogóle nie czyści pamięci. Może się przydać przy testowaniu, krótkich zadaniach, czy aplikacjach, które wymagają ekstremalnie niskiego opóźnienia (eliminacja przestoju związanego z GC = profit!).

Drugi - ZGC (JEP 333) - to eksperymentalny i bardzo szybki garbage collector. Czas czyszczenia ma zajmować mniej niż 10ms, ale na razie jest on wspierany tylko na 64-bitowych Linuxach.

Oprócz tego poprawiono wydajność metod dotyczących stringów i tablic oraz java.Math sin, cos i log na procesorach ARM AArch64 (JEP 315).

Nowa składnia, nowe możliwości

Klasa String dostanie kilka nowych metod: strip(), stripLeading(), stripTrailing(), isBlank(). Pojawi się też metoda lines(), która na pierwszy rzut oka wydaje się podejrzana, ale podobno robi to samo, co strip("\R"), tylko dużo szybciej. Od tej pory z pliku będzie można wczytać ciąg znaków przy pomocy metody readString i zapisać przy pomocy writeString.

Od Javy 11 można używać składni zmiennych lokalnych - wprowadzonej w Javie 10 - w parametrach wyrażeń lambda (JEP 323):

(var x, var y) -> x.process(y)


Java 11 wprowadza tzw. Nest-Based Access Control (JEP 181). Java pozwala na tworzenie zagnieżdżonych typów i interfejsów. W ramach zasięgu najwyższego rzędu, do którego należą, mają dostęp do prywatnych metod i pól innych zagnieżdżonych typów. Mimo to JVM sam w sobie nie umożliwiał takich wywołań i to rolą kompilatora było stworzenie odpowiednich „mostów” między typami. Skutkowało to tym, że do tej pory w wewnątrz „gniazda” nie można było użyć refleksji na prywatnych polach czy metodach. W Javie 11 mechanizm gniazd został zaimplementowany w samej maszynie wirtualnej, dzięki czemu kompilator nie musi uciekać się do sztuczek, a wywołania przez refleksję działają dokładnie tak samo jak te standardowe.

Nowa wersja wprowadza nową pulę dynamicznych stałych (co? ?) CONSTANT_Dynamic (JEP 309), co finalnie ma działać podobnie jak invokedynamic wprowadzone w Javie 7. Różnica jest taka, że nowy sposób ma być bardziej idiomatyczny i ma służyć właśnie do ustalania wartości stałych przez wywołania tzw. bootstrap methods.

Java 11 to też nowa, ustandaryzowana wersja klienta HTTP (JEP 321), który był rozwijany już w Javie 9 i 10. Teraz pakiet jest dojrzały i dostępny jako java.net.http.

Ostatnią nowością jest możliwość uruchamiania programów zdefiniowanych w pojedynczym pliku źródłowym jednolinijkową komendą (JEP 330):

java Factorial.java 3 4 5


Co jest odpowiednikiem:

javac -d <memory> Factorial.java
java -cp <memory> Factorial 3 4 5


Jeżeli chcesz bliżej zapoznać się z nowościami to zachęcam do przeczytania opisu interesującego Cię JEP-a. Wszystkie znajdują się na stronie OpenJDK 11 i pomagają zrozumieć motywacje i działanie nowości.

Warto, nie warto?

Wydaje się, że nowa wersja nie wprowadza rewolucyjnych zmian, jeżeli chodzi o stronę techniczną. Większość nowości to wynik zmian wprowadzonych w poprzednich wydaniach - praca nad tym, by Java była bardziej spójna.

Jeżeli już jesteś na Javie 10, zmiana na wersję 11 to no-brainer. 10-tka i tak kończy swój żywot, a nowa wersja nie różni się od niej dramatycznie, więc nie powinno być problemów przy migracji.

Dużo cięższy orzech do zgryzienia mają osoby, które korzystają z nadal wspieranej Javy 8. Tu jest o wiele więcej czynników - kwestia licencji, używanie modułów, które wypadły po drodze, rozmiar projektu. Pozostanie przy wersji 8 może być bardzo racjonalną i dobrą decyzją. Jeżeli jeszcze nad tym się nie zastanawiałeś/aś, to najwyższa pora dobrze przyjrzeć się swojemu projektowi i wymyślić optymalny plan działania.

<p>Loading...</p>