Java 12

Kolejna wersja Javy: Java 12, oficjalnie pod nazwą JDK 12 osiągnęła poziom w którym zamknięto zakres wprowadzanych funkcjonalności. Co zobaczymy w kolejnej odsłonie Javy?

Lista zmian, które zostaną wprowadzone:

JEP 325: Switch Expressions (Preview)

Zacznijmy od najciekawszej z punktu widzenia programisty. Rozszerzona zostaje funkcjonalność polecenia switch. Zamiast następującego kodu:

switch (day) {
    case MONDAY:
    case FRIDAY:
    case SUNDAY:
        System.out.println(6);
        break;
    case TUESDAY:
        System.out.println(7);
        break;
    case THURSDAY:
    case SATURDAY:
        System.out.println(8);
        break;
    case WEDNESDAY:
        System.out.println(9);
        break;
}

Można będzie zastosować składnię przypominającą trochę wyrażenia lambda:

switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
    case TUESDAY                -> System.out.println(7);
    case THURSDAY, SATURDAY     -> System.out.println(8);
    case WEDNESDAY              -> System.out.println(9);
}

Dodatkowo switch będzie mógł być traktowany jak metoda i jego wynik będzie można zapisać do zmiennej. Zamiast return wartość będzie zwracana istniejącym już poleceniem break.

int j = switch (day) {
    case MONDAY  -> 0;
    case TUESDAY -> 1;
    default      -> {
        int k = day.toString().length();
        int result = f(k);
        break result;
    }
};

To rozwinięcie języka służy również częściowo jako podstawa pod JEP 305: Pattern Matching

JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)

Shenandoah to Garbage Collector rozwijany przez Red Hat. Podobny do G1. Założeniem jest zredukowanie czasu które powoduje czyszczenie pamięci poprzez wykonywanie czyszczenia równolegle z działąjącymi wątkami.

JEP 230: Microbenchmark Suite

Zestaw narzędzi bazujący na Java Microbenchmark Harness (JMH) który ma umożliwić wygodne testowanie wydajności kodu źródłowego JDK. To narzędzie skierowane jest głównie do programistów rozwijających JDK.

JEP 334: JVM Constants API

Aktualnie w celu załadowania do pamięci na poziomie bytecodu stałych wymagane jest ładowanie całej klasy. To natomiast jest operacją dosyć złożoną i może spowodować szereg błędów które należałoby obsłużyć. Celem tego zadania jest stworzenie API które umożliwi wygodniejsze ładowanie stałych na poziomie bytecodu. Zmiana ta jest skierowana głównie do twórców bibliotek operujących na bytecodzie.

JEP 340: One AArch64 Port, Not Two

Aktualnie JDK zawiera dwie wersje portu ARM64, jednej z nich należało się pozbyć, żeby nie duplikować kodu i skupić się na rozwoju jednego portu.

JEP 341: Default CDS Archives

Celem tego zadania było przyspieszenie czasu potrzebnego na uruchomienie aplikacji. Według wstępnych testów osiągano 32% przyspieszenie czasu uruchomienia aplikacji HelloWorld. Tak naprawdę zmiana ta jest dostępna już w Java 11, ale, żeby z niej skorzystać należy chociaż raz wywołać polecenie java -Xshare:dumpw celu wygenerowania współdzielonego pliku. W Java 12 plik ten ma być generowany podczas budowania JDK i dostarczany razem z archiwum instalacyjnym. Ponieważ od Java 11 domyślnie przy starcie aplikacji dodawane jest polecenie -Xshare:auto to każdy użytkownik automatycznie skorzysta z przyspieszenia. Class Data Sharing (CDS) to sposób na pominięcie etapu przygotowywania klas do wczytania do pamięci. Przygotowane klasy zostają zapisane jako osobny plik (classes.jsa). Dzięki temu podczas uruchomienia nie ma potrzeby przetwarzania klas na format gotowy do wczytania do pamięci.

JEP 344: Abortable Mixed Collections for G1

Usprawnienie Garbage Collectora G1. Umożliwienie anulowania mieszanych kolekcji w przypadku gdyby czas ich przetworzenia miał przekroczyć dostępny czas. Celem jest zmniejszenie czasu w którym wirtualna maszyna jest zatrzymana w celu wyczyszczenia pamięci.

JEP 346: Promptly Return Unused Committed Memory from G1

Kolejna poprawka do która rozwija Garbage Collector G1. Tym razem chodzi o uruchamiania collectora w momencie gdy aplikacja jest w stanie spoczynku, zamiast tylko wtedy gdy kończy się dostępna pamięć. Ponieważ sporo dostawców usług chmurowych rozlicza swoich klientów na podstawie zużycia zasobów (w tym RAM) to ta zmiana może mieć spore znaczenie ekonomiczne. Aktualnie jest tak, że dopóki JVM ma dostępną pamięć to nie ma potrzeby jej czyszczenia. Doprowadza to do sytuacji, że aplikacja która niewiele robi zajmuje gigabajty pamięci ram. Zmiana w tym JEPie ma na celu częste włączanie Garbage Collectora, żeby maksymalizować czyszczenie pamięci. Testy wykazały nawet 85% niższe zużycie pamięci RAM w przypadku aplikacji webowej opartej na Tomcacie, która w większości była bezczynna w godzinach nocnych.

Java 12: Podsumowanie

Z punktu widzenia programisty Java 12 zmieni się niewiele. Dodane zostały "jedynie" rozbudowane switche. Należy jednak pamiętać, że Java jest aktualnie wydawana co 6 miesięcy. Jeśli co pół roku dodawane będą podobne zmiany to nie ma na co narzekać. Inspiracja: https://www.infoq.com/news/2018/12/jdk-12-new-features