Android dostaje wsparcie dla JDK 11 – JVM Weekly #100

1. Pierwszy nowy JEP od długiego czasu!

Od pewnego czasu nie mieliśmy okazji informować Was o żadnych nowych JEP-ach. Powody są (podejrzewam) dwa: sezon wakacyjny oraz okres przygotowywania premiery nowego JDK. Powoli jednak sierpień zbliża się ku końcowi, JDK 19 otrzymało już swojego pierwszego Release Candidate, można więc myśleć o przyszłości. Stąd mam niewątpliwą radość poinformować Was, że w naszej setnej edycji pojawia się kandydacki JEP 429: Extent-Local Variables (Incubator). Przyjrzyjmy się zatem, co się za nim kryje.

Czym są extent-local variables? Jest to alternatywa dla istniejącego ThreadLocal, stworzona jako kompan Project Loom. Ich celem jest umożliwić współdzielenie niemutowanych danych w obrębie i pomiędzy wątkami. Ich użycie wyglądać ma w następujący sposób.

final static ExtentLocal<...> V = new ExtentLocal<>();

// In some method
ExtentLocal.where(V, <value>)
           .run(() -> { ... V.get() ... call methods ... });

Powyższa struktura posiada kilka zalet. Po pierwsze, umożliwia określenie bardzo konkretnego zakresu „obowiązywania” zmiennej – coś czego nie dało się uzyskać w przypadku zwykłego ThreadLocala, będącego swoistym workiem na dane. W powyższym przypadku, V nie posiada metody .set – jest więc (niestety, wyłącznie w „płytki” sposób) niemutowalne, dodatkowo powinno być deklarowane jako final, a jej wartość ustawiana jest wyłącznie w metodzie where. W nieco zawiły, ale efektywny sposób rozwiązać ma to problem przypadkowej podmiany wartości referencji pochodzącej z ThreadLocala.

Co ze starym, dobrym, przyzwanym już w tym tekście ThreadLocal? Tutaj uspokoję: nowy typ zmiennych z JEP 429 nie ma na celu jego zastąpienia i wymuszania jego migracji. Oba rozwiązania będą żyły równolegle. Polecam jednak lekturę nowego JEP-a każdemu (świadomemu) użytkownikowi ThreadLocal – przy motywacji rozszerzenia Javy o extent-local variables, twórcy wypunktowali sporo wad (ale również zalet) istniejącego rozwiązania.

Po powyższym JEP-ie widać, jak mocno Loom kieruje dalszym rozwojem języka. A jak już o Loomie mowa…

Źródła

• JEP 429: Extent-Local Variables (Incubator)

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Jetty dostaje wsparcie dla Projektu Loom

Jetty, biblioteka dostarczająca samodzielną implementacje web server i kontenera servletów, pozostaje jednym z najpopularniejszych rozwiązań tego typu. Wprawdzie konkurencja pod postacią choćby Embedded Tomcat, Undertow czy Netty dość mocno go ostatnio podgryza, to jednak z perspektywy programistów bardzo dobra nowina – konkurencja wymusza ciągły rozwój. Dlatego też z radością informujemy o oficjalnym wsparciu projektu dla Looma.

Zmiany wejdą w życie wraz z nowymi wersjami Jetty’ego 10.0.x (najpierw wspierana ma być 10.0.x), ale całość przyciąga wzrok nie tylko z powodu bycia kolejnym dużym projektem wspierającym Looma. Osobiście uważam za bardzo uroczy fakt, że sam Alan Bateman zasugerował w zamkniętym PullRequeście poprawki, które twórcy wprowadzili. Jest dla mnie zawsze coś bardzo uroczego w tym, jak twórcy Javy odpowiadają na wątki redditowe/hackernewsowe czy właśnie robią Code Review projektom.

Jeśli ktoś jest ciekawy jak całość została zaimplementowana – tutaj macie konkretny commit.

Źródła

• Support Loom #8007

3. Android 13 przynosi wsparcie Javy 11

Początkiem tygodnia premierę miał nowy Android 13. Dobrze pokazuje to pewną zmianę myślenia o tym systemie. Kiedyś była to naprawdę duże wydarzenie, dziś premiera w tym wypadku oznaczała „zmergowanie” całości do głównej gałęzi AOSP (Android Open-Source Project) oraz wypuszczenie nowej wersji na Pixele, w oczekiwaniu na ruchy reszty graczy rynkowych – trochę jak to ma miejsce w wypadku Kernela Linuxa. Również lista nowości z mojej perspektywy jest dosyć zbliżona – z punktu widzenia użytkownika, Android 13 to trochę większe możliwości personalizacji (min. wersji językowej konkretnych aplikacji)

Z punktu widzenia programisty jest trochę więcej. Oczywiście, mamy standardowe poprawki wydajnościowe (lepszy Garbage Collector i szybszy dostęp JNI) poza tym nowości dla programistów, jak nowe API do fontów ułatwiające np. pracę z nie-łacińskim alfabetem czy lepszy performance renderingu, a także wsparcie dla standardu COLRV1. Pojawia się też min. wsparcie dla Bluetooth LE Audio czy MIDI 2.0, a także lepsza obsługa shaderów. Wisienką na torcie jest masa nowych uprawnień, które twórcy muszą zbierać od użytkowników przed dostępem do ich danych.

Jednak główny powód, dla którego tutaj piszę, jest przejście Androida na JDK 11. Najnowsza edycja wewnętrznie przeszła na Java 11, wprowadzając do platformy min. Możliwość używania var, VarHandle z java.utl.concurrent czy wielu innych pomocniczych API (jak ifPresentOrElse() na Optionalach ❤️). Widać, że wyniki procesu Google/Oracle z zeszłego roku rozwiązały twórcom ręce i powoli będą wdrażać nowości z Javy do Androida.

Pełną listę zmian znajdziecie tutaj od nieocenionych XDA Developers.

BTW: Wiedzieliście, że Google dalej internalowo używa nazw deserów do nazywania kolejnych wersji Androida? „Trzynastka” to internalowo „Tiramisu”.

Źródła

• Android 13 is in AOSP!
• Android 13 “Tiramisu”: Everything we know so far about Google’s next big update!

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

4. (Kotlinowy) Release Radar

A na koniec – Release Radar. Tym razem taki mocno Kotlinowy.

graphql-kotlin 6.0

Używacie GraphQL? Jeśli tak, specjalnie dla Was zaczniemy od nowego, dużego wydania Kotlin GraphQL, biblioteki rozwijanej przez ExpediaGroup. Dzięki nowemu wydaniu, dużo prostsze ma być propagowanie kontekstu kortyn, który teraz będzie bezpośrednio dostępny dla użytkowników API. Całość otrzymała też wszystkie poprawki pochodzące z graphql-java, nad którą jest wrapperem – twórcy zaktualizowali „bebechy” do jej wersji 18. Biblioteka otrzymała też wsparcie dla specyfikacji Apollo Federation w wersji v2, ułatwiającej modularyzację GraphQL-owego „grafu”, a także APQ – Apollo Automatic Persisted Queries.

A jak już jesteśmy przy temacie GraphQL i Apollo, to twórcy Apollo Kotlin poszli bardzo mocno w Multiplatform, a sama platforma dostała nowy Memory Manager, który stanie się oficjalnie obowiązującym rozwiązaniem wraz z premierą Kotlin 1.7.20.

Kotlin API for Apache Spark 1.2

Teraz wywołujemy do odpowiedzi użytkowników Sparka. Nowe Kotlin API for Apache Spark 1.2 to duży powiew świeżości dla użytkowników Sparka, ponieważ po długim okresie oczekiwania twórcy wreszcie dostarczyli wsparcie dla wcześniej niedostępnych User-defined Types i User-Defined Functions. Teraz twórcy aplikacji mogą tworzyć za pomocą Kotlinowego API nowe struktury danych, a także operatory, które potem można użyć w trakcie querowania zbioru danych. Zwiększona też została kompatybilność z Jupyter Notebookiem.

Oprócz tego sportowano scalowe API dla Resilient Distributed Datasets – do tej pory podstawą był wariant javowy, który jednak posiadał kilka ograniczeń, wymuszonych przez ograniczoną ekspresyjność samej Javy. Jako, że Kotlin jest pod tym względem nowocześniejszym językiem, zdecydowano się oprzeć nowy wariant API o edycje Scalową.

Ciekawostka: żeby zachować pełną kompatybilność ze Sparkiem i edycją scalową, JetBrains wypuściło 14(!) różnych wersji API, wspierających kombinacje Sparka od 3.0.0 do 3.3.0 oraz Scali od 2.12 do 2.13 – robią to dla wszystkich tych, którzy z jakiegoś powodu nie są w stanie używać na produkcji najnowszych wersji któregoś z projektów.

Ktor 2.1

A na koniec – Ktor. Jeden ze standardowy projektów JetBrains doczekał się bowiem pierwszej dużej aktualizacji po wydaniu wersji 2.0.

Nowy Ktor to przede wszystkim narzędziówka. Przede wszystkim pojawiło się ktor CLI (co ciekawe, napisany w Kotlin Native!), umożliwiający stworzenie nowego projektu. Narzędzie dostępne jest na razie na macOS i Linux, z wersją Windows dostępną w przyszłości. Instrukcje pobrania znajdziecie w oficjalnym repozytorium projektu.

To jednak nie jedyny nowy sposób na tworzenie nowego projektu ze wsparciem ktor’a. Pamiętacie jeszcze Yeomana? Ten kiedyś bardzo popularny frontendowy generator projektów z biegiem lat rozszerzył swój zakres działania, dostarczając tak zwane „generatory” przeznaczone również na inne stacki technologiczne. Tym razem padło właśnie na Ktora. Przyznać się, kto używał lub używa jeszcze yeomana?

Ostatnim z narzędzi które mogą nam ułatwić pracę z ktor-em jest nowy plugin gardle, ułatwiający releasowanie aplikacji. Wynikowy artefakt może być teraz łatwo skonfigurowany z pomocą gradlowego DSL do postaci FatJara, obrazu Dockerowego lub GraalVM-owej binarki.

A w bonusie: Fani YAMLa mogą zaś teraz używać właśnie tego standardu do definiowania konfiguracji.

Źródła