Dzisiejsza edycja odbywa się zdecydowanie pod znakiem Kotlina – jednak również i dla zainteresowanych Javą pojawił się ciekawy temat, pokazujący jak bardzo trudnym procesem jest pozbywanie się funkcjonalności z języka. Zapraszamy do lektury!
1. Kotlin 1.5 wyreleasowany
Czekaliśmy długo, jak chwalą się twórcy w oficjalnym blogpoście ogłaszającym premierę. To pierwsze duże wydanie Kotlina w tym roku. Wiele z funkcji, które przynosi mieliśmy już okazję opisywać przy okazji wydania 1.4.30, stanowiącego de facto preview 1.5, ale gwoli przyzwoitości przejdźmy przez zmiany, jakie wprowadza nowa wersja.
Do nowej edycji języka trafia kolejna iteracji “reprezentacji pośredniej” (IR) kodu dla JVMa, czyli zdecydowanie najważniejszej i najczęściej używanej wersji, ponoć multiplatformowego Kotlina. Kompilator języka ma być znacznie szybszy (co do tej pory było jego piętą achillesową), a sama nowa 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, Sealed Classes, Inline Classes, a także możliwość kompilacji do Single Abstract Methods i Lambd ze wsparciem invokedynamic. Całość ma doprowadzić do interoperatywności między Javą i Kotlinem na niespotykanym wcześniej poziomie. Większość wspomnianych featurów została eksperymentalne udostępniona w ramach wydania 1.4.30 – teraz możemy już z czystym sumieniem używać ich na produkcji. Chyba, że wymagacie zgodności z Javą 1.6 – Kotlin porzuca ostatecznie wsparcie dla tego runtime – wymagane minimum teraz to JVM 1.8.
Prawda jest taka, że poza małymi usprawnieniami w API (zarówno języka, jak i testów), jakichś drobiazgach dla Kotlina Native oraz zapowiedzią nowej IR dla Kotlin/JS – niewiele jest w nowej wersji innych dużych rzeczy. Widać, jak czasochłonnym i męczącym procesem było dopasowanie się do nowych zmian w JVM. Teraz z dużym zaciekawieniem czekam na kolejną iterację kotlinowej roadmapy – mam nadzieje, że pokaże nam ona stojące na własnych nogach zmiany, które przedstawią dalszy kierunek ewolucji języka.
W okolicach Kotlina 1.5 doszło też do innej, interesującej premiery. kotlinx-serialization otrzymała kolejną edycję 1.2, a wraz z nią dopasowanie do nowych możliwości Kotlina 1.5 (jak np. Value classes) oraz szybszą serializacją JSONów. kotlinx-serialization łatwo przegapić, a stanowi on istotny budulec wielu bibliotek, działając jako swego rodzaju biblioteka standardowa do serializacji/deserializacji, której (pomimo usilnych prób ludzi od Jakarty EE) tak brakuje w Javie.
Ale to nie ostatnia z kotlinowych zapowiedzi z zeszłego tygodnia…
Źródła
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!
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Jetpack Composer rozpycha się łokciami
Przyznam, że choć wiele wspólnego nie mam już w tej chwili ani z aplikacjami desktopowymi, ani mobilnymi, to jednak Jetpack Compose należy do projektów, którym naprawdę bacznie się przyglądam. Do macierzystego Androida i ciągle rozwijanej edycji desktopowej w zeszłym tygodniu dołączyła wersja przeznaczona na… przeglądarki.
W przestrzeni webowej konkurencji nie brakuje – poza frameworkami natywnymi dla JavaScripta, pokroju Vue, Angulara czy Reacta, są przecież rozwiązania nieco mniej ortodoksyjne – żeby wymienić tutaj choćby Fluttera. W odróżnieniu od tego ostatniego, który opiera się na rysowaniu interfejsu na obiekcie Canvas, Jetpack Compose for Web ma opierać się na tworzeniu drzewa DOM z poziomu kodu aplikacji. Sprawia to, że jako rozwiązanie przypomina nieco JSX, aczkolwiek zamiast wzbogaconego DOMa mamy tutaj do czynienia z ładnie komponowalną, ale jednak mocno kotlinową składnią. Oprócz API opartego o DOM, nowa biblioteka zawiera również opcje na dzielenie komponentów z wersjami mobilnymi czy desktopowymi – te mają być odbudowane za pomocą semantycznego DOMa. I to właśnie w wypadku użyć wraz z innymi dobrodziejstwami Kotlin Multiplatform widzę największą przyszłość tej technologii. Na tym etapie, biorąc pod uwagę mnogość alternatywnych, konkurencyjnych rozwiązań, traktować należy, co najwyżej jako ciekawostkę.
A co powiecie na możliwość użycia Jetpack Compose do tworzenia… aplikacji Shellowych? Otóż świetnie znany w community Jake Wharton (kiedy jeszcze pisałem aplikacje na Androida, ten człowiek odpowiedzialny był za połowę moich zewnętrznych zależności) zaprezentował Mosaic. Przy okazji tego projektu dowiedzieć się można o samym Compose – jego możliwości wychodzą poza tworzenie warstwy prezentacji, czego można się nauczyć z kodu źródłowego projektu.
A, jeżeli chcecie pobawić się wersją desktopową Jetpacka, Sebastian Aigner – Developer Advocate z Jetbrains – stworzył tutorial pokazujący, jak krok po kroku odtworzyć klasyczną grę “Asteroids”. Miłej zabawy.
Źródła
- Technology Preview: Jetpack Compose for Web
- JakeWharton/mosaic
- How I
built an „Asteroids” game using Jetpack Compose for Desktop
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!
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Security Manager usuwany z Javy – nie bez kontrowersji ♀️
Po dwóch tematach kotlinowych pora przejść do czegoś javowego – wiemy, że choć język stworzony przez Jetbrainsów jest niezwykle popularny, to jednak na JVMie niepodzielnie rządzi jednak Java. Dlatego też dzisiejszą edycje kończymy JEPem. Jednak zamiast po prostu, jak to mamy w zwyczaju, podzielić się, nad czym ciekawym architekci języka dumają – dzisiejszy proposal okraszony jest odrobiną kontrowersji z dość nieoczekiwanego kierunku.
Zacznijmy jednak od podstaw – JEP 411: Deprecate the Security Manager for Removal przynosi to, co programiści lubią najbardziej – usuwanie kodu. No, może niekoniecznie usuwanie, ale deprekracja to w końcu pierwszy krok ku pozbyciu się nadmiarowego balastu. A mówimy tutaj o balaście dosyć wiekowym – Security Manager swoje korzenie ma jeszcze w pierwszym wydaniu Javy. Jego głównym celem było (i w zasadzie ciągle jest) możliwość granularnego sterowania uprawnieniami aplikacji uruchamianych w ramach JVM. Jest to opcja swoistej piaskownicy, pozwalającej np. ograniczyć dostęp do systemu plików albo zablokować wykonanie komend pokroju System.exit() – do tego używają go np. serwery aplikacyjne. Jego użycie szczególnie istotne było w epoce, gdy aplikacje javowe często były np. pobierane z sieci w formie apletów. Jednak jak to bywa ze starymi API, Security Manager był skomplikowany i niewydajny. Dzisiaj, wraz z powolnym odchodzeniem do niebytu Javy jako platformy do uruchamiania plików *.jar, twórcy JDK zdecydowali się na usunięcie go z platformy.
I tutaj cały na biało wchodzi… NetBeans. Pamiętacie jeszcze to IDE, chyba pierwsze tego typu narzędzie dla Javy, rozwijane jeszcze przez Sun? Otóż z faktem, że oprogramowanie jest niemal tak stare jak cała platforma, w jego bebechach drzemie wiele prehistorycznego kodu – w tym takiego mocno opierającego się właśnie na Security Managerze. Używają oni Security Managera do dość nietypowych zastosowań jak np. ochrona dostępu do konkretnych ścieżek systemu plików, czy śledzenie okien pop-up użytkownika. W swoim poście proszą oni o komentarz i propozycje alternatyw, które mogą użyć.
W całej sprawie wypowiedział się sam Ron Pressler w dość długiej publikacji na inside.java, gdzie zaprezentował, jak można emulować niektóre z zachowań Security Managera np. za pomocą systemu modułów. Nie twierdzi on, że nie pojawią się pewne luki, ale chęć usunięcia motywowana jest drogim kosztem utrzymania oraz… faktem, że jego sposób zachowania nie jest kompatybilny z wirtualnymi wątkami. Jak już kiedyś pisaliśmy, interesująco patrzy się na inkrementalny proces dostarczania Projektu Loom – mamy tutaj do czynienia z kolejnym JEPem czyszczącym przedpole zapowiadanej rewolucji.
Źródła
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
