JVM Tuesday vol. 47

1. Kompletna lista funkcjonalności w Javie 17

Java 17 weszła w dniu dzisiejszym w Rampdown Phase Two – oznacza to, że obecnie jesteśmy chyba w tym martwym okresie, gdy w pełni wyklarowała się już wizja Javy 17, i aktualnie pełny nakład sił kładziony jest nie na dokładanie rzeczy do backogu, a na spinanie do kupy obecnego zakresu prac – a zapewne, dołożył się do tego też sezon urlopowy. Żadne dodatkowe zmiany w JEPach nie pojawią się już w siedemnastej edycji (która jak chcemy przypomnieć, będzie wersją Long Time Support), a twórcy skupią się wyłącznie na poprawie błędów o najwyższym priorytecie. Dlatego też stwierdziliśmy, że jest to dobry moment, aby przyglądnąć się temu, co też twórcy Javy postanowili nam zaprezentować w nowym wydaniu.

Zacznijmy od tych JEPów, które mieliśmy już okazję dla Was opisywać:

O usunięciu Applet API pisaliśmy w naszej edycji 30tej
Project Lanai i JEP 382 (New Rendering Pipeline) pojawił się zaś w edycji 27
JEP 356 Enhanced Pseudo-Random Number Generators – to vol. 23…
…zaś w vol 26 opisywał już JEP-406 Pattern Matching for switch (Preview)
Mocniej Enkapsulowane Internale (JEP-403) to edycja 36
zaś usunięcie Security Managera gościło u nas już dwukrotnie – w edycji 37 i 38
oraz (lekko naciągane) poruszaliśmy już temat wersji Javy na macOS/ARM w edycji 22

Chyba tym małym “flexem” udowodniłem, że dla regularnych czytelników naszego Weekly nowa edycja Javy nie powinna przynieść większych zaskoczeń.

Tak naprawdę nie ma czego tutaj bardzo opisywać. Z drobiazgów, które do tej pory się nie przewinęły przez poszczególne edycje, mamy bardzo niskopoziomowe zmiany w sposobie reprezentacji Floatów (JEP 306 – Restore Always-Strict Floating-Point Semantics) i znajdujące się w inkubacji dalsze elementy Projektu Panama (którym pewnie przyjrzymy się bliżej już w okolicach premiery nowego JDK). Oprócz tego, naszej uwadze umknęły deprekacja RMI (co akurat jest dość ciekawym tematem) oraz eksperymentalnych kompilatorów AOT oraz JIT (co jest, mam nadzieję, czyszczeniem pola przed zapowiedzianym swego czasu projektem Leyden).

Finalnie Java 17 przyniesie też w końcu ostateczną wersję Sealed Class – aczkolwiek po kilku inkubacjach nie potrafię już “jarać” się tym featurem.

Kolejny raz jednak warto wspomnieć o JEP-466 – Deprekacji Security Managera – która w tej chwili chyba stoi na czele najbardziej kontrowersyjnych zmian w platformie w ostatnich latach, będąc najszerzej dyskutowaną zmianą od czasu Module Systemu. Rzutem na taśmę, twórcy zaktualizowali jeszcze nieco zakres prac w ramach tego proposala. Nareszcie (pewnie gdyby od tego zaczęto, backlash byłby nieco mniejszy) przedstawiono przyszłość kolejnych etapów, oraz jak całość będzie stopniowo wycofywana. Nie jest to nic nowego, o czym nie można było już wyczytać, ale fajnie mieć to dobrze rozpisane w jednym miejscu.

Źródła

JDK 17 Schedule

2. Pojawiają się nowe inicjatywy w ramach JDK

Dawno nie było u nas JEPów, co? Ostatnio mało jest takowych, bo w końcu trwają prace nad finalizacją Javy 17. Nie oznacza to jednak, że na listach mailingowych Javy nie dzieje się nic ciekawego. Dzisiaj więc zrobimy sobie małą “przekrojówkę” najświeższych pomysłów, bowiem ostatnimi czasy pojawiły się tam dwie ciekawe inicjatywy.

Jedną z nowych propozycji jest Project CRaC (co za urokliwa nazwa). Stojący za nim Anton Kozlov z Azula uważa, że aplikacje javowe mogą uniknąć długiego uruchamiania i procesu “rozgrzewania”, zapisując pełny stan środowiska uruchomieniowego. Zapisany stan może być następnie używany do szybkiego uruchamiania konkretnej instancji – całość przypominać ma nieco, jak działa proces zapisu stanu w emulatorach gier. Dodatkowo, wiele instancji może wypączkować z takiego pojedynczego “savestate”. Oczywiście wiąże się z tym trochę problemów (samo środowisko uruchomieniowe może się zmienić, wspomniana wieloinstancjowość też jest wyzwaniem), dlatego sugeruje on “reasearch” nad odpowiednimi API w ramach Javy, które mogłyby sobie ze wspomnianymi problemami poradzić i umożliwić wielość opcji, jeśli chodzi o miejsce, gdzie wspomniany stan można by było “zrzucać”. Projekt ma być szczególnie istotny w środowiskach chmurowych, gdzie długi rozruch jest istotnym wyzwaniem.

Wprawdzie szybko pojawiły się głosy, że inicjatywa przypomina nieco wprowadzony w JDK 13 Application Class Data Sharing, ale osobiście lubię wielotorowość, którą ostatnimi czasy obserwuje w świecie JVMa.

To nie jedyna z nowości – otóż w ramach list mailingowych trwa również dyskusja nad wsparciem Waylanda. Wayland to następca legendarnego X11, czyli “serwera wyświetlania” (nienawidzę tłumaczenia tej nazwy) w ramach Linuxa. Do tej pory aplikacje javowe uruchamiały się w nim poprzez warstwę kompatybilności z X11, ale widać, że twórcy JDK powoli przymierzają się do wsparcia natywnego. Mamy więc do czynienia z dalszymi krokami w stronę modernizacji całego okienkowego “stacku” JVM, świetnie wpisującymi się w działania JetBrains w ramach JEP 382 – Project Lanai (czyli obsługi Matal API na MacOS, która jak pisaliśmy, trafi do Javy 17) czy inwestycjami w desktopowego Jetpacka.

Źródła

3. Może trochę Advent of Code z Kotlinem w połowie lipcu?

Może nie jest to wielki news, ale i tak postanowiliśmy się podzielić faktem, że JetBrains na oficjaln
ym kotlinowym blogu postanowiło rozpocząć serię zadań z Advent of Code w Kotlinie. Na razie jest to pierwsze zadanie, ale autorka już zapowiedziała chęć kontynuacji całej serii, więc mamy nadzieje, że niedługo pojawią się kolejne posty.

Ale czym ten cały Advent of Code jest? Chyba nie ma lepszej osoby żeby wyjaśnić, niż autor samego przedsięwzięcia…

https://www.youtube.com/watch?v=CFWuwNDOnIo

… przy czym rozumiemy, że nie każdemu chce się słuchać 40 minut prezentacji więc TLDR: Jest to coroczny konkurs programistyczny, polegający na rozwiązywaniu przez 24 dni zadań o coraz wyższym poziomie trudności . O ile wiele osób traktuje go mocno ambicjonalnie, to dla nas zawsze był okazją do przedświątecznego rozruszania mózgownicy (tak, prywatnie bawimy się się już któryś rok z rzędu). Bo pamiętajcie, Advent Of Code to przede wszystkim jest dobra zabawa

Inicjatywa JetBrains z tego powodu strasznie nam się podoba. Nauka przez zabawę to zwykle najlepsza z metod, a możliwość zobaczenia, jak poszczególne zadania rozwiązać w najbardziej idiomatyczny sposób jest czymś bardzo kuszącym. Nawet dla osób (tak jak piszący te słowa), które właśnie w Kotlinie zrealizowały całą poprzednią edycję – zawsze można sobie potraktować blog posty od JetBrains jako swoiste Kata i skorzystać na braku goniącego limitu czasowego (a ten w Advent of Code czasem daje w kość).

Dodatkowo, chcielibyśmy przypomnieć wszystkim, którzy do tej pory nie bawili się w Advent of Code, że w zeszłym roku Vived udało się zebrać grupę ponad 80 osób, z którymi wspólnie ścigaliśmy się na rozwiązywanie zadań. Grupę chcemy powiedzieć dość mocarną, gdyż prawie dwudziestu spośród uczestników wykonało wszystkie dwadzieścia zadań na obie gwiazdki. Już w tej chwili chcieliśmy zaś zaprosić wszystkich do wspólnej zabawy w grudniu – obiecujemy być z Wami od pierwszego dnia, może nawet przygotujemy w tym roku jakieś nagrody.

Źródła

‌Pamiętajcie, żeby spróbować Vived, jeśli chcesz otrzymywać tego typu treści spersonalizowane pod Ciebie!

1. Kompletna lista funkcjonalności w Javie 17

Źródła

2. Pojawiają się nowe inicjatywy w ramach JDK

Źródła

3. Może trochę Advent of Code z Kotlinem w połowie lipcu?

Źródła

Odkryj więcej świetnych treści!