Dzisiejsza edycja jest bardzo ważna – mamy okazję po raz pierwszy pogadać o nadchodzących featurach JDK 16 i zaskakująco interesującym minorowym releasie Kotlina. Uronimy też łezkę nad niedługo świętej już pamięci JCenter 😭 Zapraszam do lektury!
1. Release Candidate JDK 16 – Przegląd nowych featurów
Powinniśmy zacząć od chyba najważniejszego wydarzenia w ekosystemie JVM od początku roku – otóż opublikowany został pierwszy Release Candidate Javy 16, a wraz z nim otrzymaliśmy zarówno finalną listę JEPów, które trafiły do nowego wydania, które ukaże się 16 marca.
Jeżeli miałbym szukać tematu przewodniego nowego wydania Javy, to myślę, że wskazałbym tutaj interoperacyjność z “natywnym” systemem operacyjnym. Głównie poprzez Projekt Panama, ale nie tylko. Do inkubacji trafiło Vector API [JEP-338] oraz Foreign Linker API [JEP-389] (dla tych, którzy chcą poznać je lepiej, polecam fantastyczne odcinki podcastów stanowiących czytelny wstęp w temat – znajdziecie je w źródłach). Wprowadzona została również obsługa elastycznego Metaspace [JEP-387], które teraz podzielone jest na regiony, co umożliwia bardziej dynamiczne zwracanie pamięci zajętej przez metadane klas do systemu operacyjnego. Dla tych, co lubią ręczne grzebanie w pamięci – Foreign-Memory Access API (JEP-393) dostało trzecią iterację inkubacji.
Bardzo ciekawą opcją na systemach Unix jest też możliwość komunikacji z procesami systemowymi bezpośrednio po sockecie [JEP-380]. Do sprawdzenia, jakie możliwości to daje, niech posłuży ten artykuł, którego autor pokazuje, jak wykorzystać tą opcję do komunikacji z PostgreSQL.
Trivia: sam kod JDK jest teraz kompilowany za pomocą C++ 14 [JEP-347]. Do tej pory używana była do tego mocno archaiczna wersja z roku 98.
W naszych JVMowych edycjach temat procesorów ARM przewija się dość często. Wraz z nową Javą, o potędze nowoczesnych niskonapięciowców przekonać mogą się również użytkownicy Windowsów – wersja ARM okienek doczekała się własnego portu Javy [JEP-388]. Co ciekawe, nie jest to jedyny port Javy na nowy system, który przynosi to wydanie. Moim wielkim zaskoczeniem przy czytaniu release notesa był fakt, że JDK nie wspierał popularnego Alpine, a to dlatego, że zamiast popularnego glibc jego główna implementacja C to musl. Do tej pory wszelkiej maści obrazy dockerowe oparte o Alpnie musiały używać zewnętrznych portów gclib, od teraz dzięki Projektowi Portola możliwe będzie uruchomienie JDK na czystym systemie [JEP-386].
Nowa wersja JDK to także finalizacja dobrze znanych z poprzednich wersji Rekordów [JEP-395], Packaging Toola [JEP-392] oraz Pattern Matchingu (dla instanceof) [JEP-394], które ostatecznie wyszły z inkubacji i trafiły do finalnej wersji języka. Jeżeli jesteście zainteresowani tymi częściami języka, napisano już w internetach naprawdę dużo (najciekawsze moim zdaniem opracowania znajdziecie w źródłach). Sealed Classy nie miały tyle szczęścia – ukazał się ich drugi preview [JEP-397]. To, co w ich przypadku najbardziej zaskakuje, to nowy syntax, a konkretnie non-sealed – po raz pierwszy mamy do czynienia z łącznikiem w słowie kluczowym. Ciekawe, czy jest to początek nowego trendu.
public non-sealed class Square extends Shape { ... }
A, i Java ostatecznie (wraz z ukończeniem prac nad Project Skara) przenosi się z Mercuriala na Gita [JEP-357], co pozwoliło uczynić GitHuba “upstreamem” całego OpenJDK [JEP-369].
To była długa sekcja, ale mam nadzieję, że udało nam się logicznie uporządkować to co przyniesie marzec. Tak naprawdę na codzienne programowanie wpłyną raczej znane już rzeczy, które po prostu osiągnęły stabilność (Rekordy i Pattern Matching), ale nowa wersja powinna trafić również w bardziej niszowe gusta.
Źródła:
- JDK 16: First Release Candidate (tutaj też znajdziecie odnośniki do wszystkich JEPów)
- Talking to Postgres Through Java 16 Unix-Domain Socket Channels
- Inside Java Podcast Episode 7 “The Vector API”
- Inside Java Podcast Episode 9 “Project Panama – The Foreign Memory Access API”
- Inside Java Podcast Episode 10 “Project Panama – The Foreign Linker API”
Zainstaluj teraz i czytaj tylko dobre teksty!
2. JFrog zamyka Bintray i JCenter
Teraz będzie na smutno.
Podejrzewam, że każdy, na jakimś etapie swojego życia (a już zwłaszcza, jeśli pisał coś w Androidzie), miał okazję wpisywać do swoich .pom lub .gradle odnośniki do repozytoriów Bintraya lub JCenter. Te alternatywy dla Maven Central stanowiły przystań dla wersji testowych zależności, niezależnych projektów. Sprawdźcie, czy wasze buildy nie mają zależności na JCenter przed 1 lutego 2022. Inaczej może Was spotkać przykra niespodzianka.
Co ja się łudzę, ta informacja i tak zaskoczy wielu developerów jak zima drogowców (chyba, że będą czytać nasze JVMowe wtorki, bo na pewno o tym przypomnimy).
Użytkownicy Javowego Reddita opracowali dobrą listę alternatyw, ale i tak umiera na naszych oczach kawałek historii.
Prywata: Łezka zakręciła mi się w oku, bo to właśnie Bintray jest domem mojego jedynego prawdziwego autorskiego projektu Open-Source. Newton
był warstwą abstrakcji nad API Beaconów BLE w czasach, kiedy Kraków znany był jako Beacon Valley . Nigdy nie zdobył popularności, właściwie ciężko mi powiedzieć czemu, choć podejrzewam, że jeśli miałby choć linijkę Readme, to by poszło mu przynajmniej odrobinkę lepiej .
Źródła:
- Into the Sunset on May 1st: Bintray, JCenter, GoCenter, and ChartCenter
- Hearing jcenter() is close to an end do you know any good alternative ?
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Kotlin 1.4.30 – znacznie ważniejszy niż sugeruje numeracja
I na koniec, jak to często bywa, Kotlin i jego świeżutkie jeszcze wydanie 1.4.30. O ile zwykle nie informujemy o minorowych wersjach języków, o tyle nowa wersja Kotlina przynosi za sobą taką mnogość interesujących nowości, że aż nie wypada jej pominąć w opracowaniu tygodnia. Można ją de facto traktować jako przedsmak tego, co przynieść ma nam Kotlin 1.5. Pamiętacie, jak w zeszłym tygodniu pokazywaliśmy Wam Kotlinową Roadmapę? Otóż już dzisiaj mamy okazję pobawić się dwoma istotnymi nowościami, które były w niej zawarte.
Do nowej wersji języka trafia nowa “reprezentacja pośrednia” (IR) kodu dla JVMa, czyli zdecydowanie najważniejszej i najczęściej używanej wersji, ponoć multiplatformowego Kotlina. Co ciekawe, Jetbrains chwali się, że są na tyle pewni tego wydania, że mogą zarekomendować “zabawy” z nowym IRem również na produkcji. A jest się, czym bawić. Kompilator Kotlina ma być znacznie szybszy (co do tej pory było piętą achillesową tego języka), a sama reprezentacja odblokowuje dynamiczniejsze nadążanie za zmianami w samej Javie.
Za dowód, że twórcy nie rzucają słów na wiatr, niech posłuży druga duża nowość. Do “internali” Kotlina trafiają Rekordy oraz Sealed Classy. Oczywiście w wersji eksperymentalnej (żadne z nich nie jest stabilne nawet w JDK, i jeśli czytaliście sekcje o JDK 16, to wiecie, że w najbliższym czasie spodziewać się należy tylko Rekordów), ale sam fakt, że już teraz można je wypróbować, dobrze wróży na przyszłość. Twórcy obiecują, że trafią one do Kotlina w wersji 1.5, a jeden z featurów języka (Value Classy) doczekać się ma też wsparcia dla Projektu Valhalla, gdy ten tylko zagości w JDK. Całość ma doprowadzić do interoperatywności między Javą i Kotlinem na niespotykanym wcześniej poziomie, i co mogę powiedzieć…
PS: Wspomniane Value Classy doczekały się jednego z najlepszych publicznych Design Doców jaki miałem okazję widzieć – Elizarov zaszalał. Nie jest to szybka lektura (pierwsze przejście przez całość zajęło mi prawie 2h, a żeby wszystko zrozumieć pewnie musiałbym zrobić drugie podejście). Ale właśnie za takie rzeczy uwielbiam otwartość ekosystemu JDK i bardzo cieszę się z tego, że już niedługo Java też będzie na Githubie (Brian Goetz zresztą już tam jest wraz z docsami do Project Amber).