JVM Monday vol. 21

1. Obiekty Prymitywne w Javie – „Project Valhalla” dostaje sporą aktualizację

Objaśnianie „Java Enhancement Proposali” jest zawsze interesującym procesem , a że jeden z ważniejszych otrzymał właśnie dużą aktualizacje, zaczniemy od niego dzisiejszą edycję – wspomniany JEP bardzo dobrze obrazuje kierunek zmian, w którym podąża Java jako platforma.

Wraz z Projektem Valhalla mocno zaciera się nam granica między tym, co jest obiektem, a co “językowym prymitywem”. Z jednej strony mamy choćby JEPa, zadaniem którego jest umożliwić używanie prymitywów jako parametrów generycznych. Z drugiej strony zaś postanowiono dać ludziom tworzenia swoich własnych prymitywów. Mają bowiem one swoje unikalne właściwości – np. fakt że trzymane są na stosie, a nie w heapie pozwala na przechowywanie ich bezpośrednio w cache procesora, co przy dzisiejszej architekturze hardware ma niebagatelny wpływ na wydajność. To sprawia, że nieraz niezbędne jest operowanie właśnie na nich, a nie posiadających większe możliwości obiektach. Stąd też tylko o krok do tak zwanej Primitive Obsession.

Oczywiście, nikt tak nie pisze kodu, ale w dalszym ciągu możliwość definiowania customowych, złożonych obiektów traktowanych przez język jako prymitywy daje potężne możliwości. Żeby nie było za różowo, Primitive Objects będą miały swoje ograniczenia – przykładowo, reprezentacja tego typu klas nie będzie miała stałego miejsca w pamięci, nie jest więc możliwe stworzenie kierującego do niej wskaźnika. Ma daleko idące konsekwencje, min. w tym że klasy te są “efektywnie finalne”, i “efektywnie niemutowalne”.

Zmiany które pojawiły się we wspomnianym drafcie JEPa w zeszły piątek w dużej części dotyczą terminologii (choć nie tylko). Dlatego przestrzegamy – jeżeli kiedykolwiek natkniecie się na nazwę Value Types w kontekście JDK – to właśnie mowa tam o Primitive Objects.

JEP zawiera masę ciekawych detali implementacyjnych, ale biorąc pod uwagę moje doświadczenia zarówno w wypadku Valhalli, jak i np. Looma, sugeruje się jeszcze wstrzymać z kuciem nowego syntaxu na blachę. Z pewnością się w wielu miejscach jeszcze zmieni.

Dla ambitnych: Fajna rozmowa z Reddita na temat zmian z JEPa

2. Typy zależne w Scali 3 – czym to się je

Nieco napomknąłem o tej publikacji (a ma ona dwie części – 1 i 2) w edycji sobotniej (do której regularnej lektury bardzo zapraszam), ale zdecydowanie powinna znaleźć się ona również w dzisiejszym podsumowaniu (i nie tylko dlatego, że dotyka Scali, a tej u nas ostatnio nie za dużo było). Jako całość stanowi bowiem jedno z najlepszych i najbardziej pragmatycznych wprowadzeń do Typów Zależnych, które to stanowią jedną z najciekawszych innowacji w językach programowania ostatnich lat.

Niektórzy genezy samego konceptu niektórzy upatrują się u Bertranda Russella (co uważam za cheatowanie, ponieważ w zasadzie wszystko co związane z typami można z Russellem w jakiś sposób powiązać – fascynujący człowiek). Z dzisiejszego punktu widzenia Dependent Types dostały jednak życie gdy Haskell Curry (tak, dobrze się domyślacie, że jest to dość ważna persona dla języków funkcyjnych  ƛ) zauważył, że rachunek lambda i logika kombinatoryczna mają wiele wspólnego z rachunkiem zdań, konkurencyjnym działem logiki.

Stąd już „prostą” była droga do zaprzęgnięcia komputerów do udowadniania pewnej kategorii twierdzeń, gdzie Typy Zależne okazały się być nieocenionym narzędziem. Programistów zaś zainteresowały stosunkowo niedawno, wraz z językiem Idris, który to pokazał ich praktyczną użyteczność również do tak zwanego „general programmingu”.

Więc czym Dependent Types tak naprawdę są? W uproszczeniu: są one typami zależnymi od wartości. Ta unikalna cecha pozwala na uniknięcie dużej kategorii błędów logicznych już na samym poziomie kompilacji. Najprostszym chyba przykładem jest możliwość zdefiniowania reguły, że dana funkcja przyjmuje tylko liczby parzyste (czy będąc szalenie precyzyjnym – „że jej argument należy do zbioru liczb parzystych”). Jeżeli kompilator wykryje złamanie tej reguły, przerwie proces i wyrzuci błąd.

Jeżeli czujecie się zachęceni, artykuły (a ma ona dwie części – 1 i 2) prezentują koncept znacznie szerzej na przykładzie Scali 3. Możecie znaleźć w nich nie tylko syntax, ale i interesujące przypadki użycia.

PS: Jeśli zainteresował Was temat (ale nie lubicie Scali) ta prezentacja jest bardzo dobrym, “językowoagnostycznym” jego rozwinięciem, pozwalając lepiej zrozumieć zarówno teorie jak i powiązaną z nią praktykę ‍

3. Finalna wersja gRPC trafia do Kotlina

Na koniec news z grudnia, ale sami trafiliśmy na niego z drobnym opóźnieniem, a że w stosunku do Keep-Upowej formuły (<marketing>bo pamiętajcie, Vived to aplikacja która codziennie wybiera dla Was dopasowane artykuły, pozwalając być na bieżąco z rynkiem IT</marketing>) mamy tutaj trochę więcej miejsca, spróbujemy temat nie
co rozszerzyć.

gRPC jest rozbudowaniem koncepcji Protocol Buffers, binarnego formatu służącego do komunikacji między usługami sieciowymi i aplikacjami. RPC w nazwie jest akronimem Remote Procedure Calls – okrytej złą sławą techniki programistycznej, próbującej ukrywać przed programistami fakt, że wykonania funkcji odbywają się nie lokalnie, a do jakiejś zewnętrznej maszyny (no bo co może pójść nie tak). Jednak niektóre lekcje trafiły do głowy, wnioski zostały wyciągnięte, a i sama branża w miejscu nie stoi, więc przeżywają one swój renesans. gRPC jest cenione ze względu na wsparcie dla HTTP/2 i wsparcie dla schematów  (zapewniając łatwą typowalność requestów). Dzięki tym cechom są dla niektórych projektach interesującą alternatywą dla RESTa.

Jak można znaleźć w newsie, Kotlin otrzymał stabilne wsparcie dla tego protokołu. O ile wcześniej istniały sposoby na używanie go wraz z językiem od JetBrains, to dopiero wraz z udostępnieniem biblioteki od Google możliwe jest idiomatyczne wsparcie wielu charakterystyk Kotlina, takich jak np. domyślna nienullowalność.

Wspomniany artykuł zawiera wiele linków np. do zewnętrznych tutoriali, jeżeli więc chcecie spróbować swoich sił z gRPC, jest on bardzo dobrym punktem startowym.