JVM Tuesday vol.77 – Java Flight Recorder i Context Receivers w Kotlinie

1. Społeczność sama pisze dokumentację do JDK Flight Recorder

JDK Flight Recorder (oficjalna aplikacja do monitoringu JVM) przez długi czas “latał pod radarem” większość programistów JVM. Było to oczywiście związane z faktem, że przez długi okres czasu wymagał komercyjnej wersji JDK udostępnianej przez Oracle. Choć zdarzały się oczywiście firmy, które takową posiadały, to jednak taki stan rzeczy mocno wpływał zarówno na poziom umiejętności programistów (w końcu nawet nauczyć się obsługi tego narzędzia było trudno), jak i zainteresowanie do inwestowania w jego poznanie (zbyt prawdopodobnym było, że kolejna firma, w której będziemy pracować, nie będzie miała do niego dostępu). Teraz jednak, kiedy już nareszcie całość trafiła w ręce społeczności i każdy może go swobodnie używać, powinien nastąpić jego renesans, prawda?

Ale czemu tu się dziwić, skoro przy oddawaniu całości społeczności wyraźnie zapomniano, że to nie jest tak, że wystarczy zopensourcować i “samo się podzieje”, tylko o społeczność trzeba zadbać. A Flight Recorder wydaje się być dzieckiem mocno porzuconym, mimo tego, że w kolejnych wersjach JDK zdarzało mu się dostawać jakieś drobne (a i mniej drobne) usprawnienia. Wyobrażacie sobie, że na przykład format pliku wynikowego nie jest w żaden sposób udokumentowany? Tak, też się zdziwiłem – jest to w moim mniemaniu pokłosie tego, że przez lata Oracle nie zależało na zapewnienie odpowiedniego poziomu kompatybilności z ekosystemem narzędzi – w końcu mowa była tu o oprogramowaniu zamkniętym.

Na szczęście JFR w obecnej postaci jest oprogramowaniem otwartoźródłowym, a nie każdy bohater nosi pelerynę. To właśnie na podstawie kodu źródłowego Gunnar Morling przygotował pełną specyfikację tego, w jaki sposób Flight Recorder działa, wraz z bardzo dokładnym diagramem. Ten reverse engineering (aczkolwiek skoro mamy dostęp do kodu określenie to jest pewnym nadużyciem) pozwolić ma na stworzenie alternatyw do oryginalnych narzędzi Oracle, a także integracje całości z całym ekosystemem tooli do monitoringu.

Kto wie, może praca Gunnara da JFR-owi drugie życie?

Źródła

2. Kolejna alternatywa do dziedziczenia w Kotlinie – Context Receivers

Wersje 1.x.20 są dla Kotlina bardzo istotne, stanowią bowiem zwykle swoiste preview przed kolejnym dużym wydaniem, dają więc szanse na przetestowanie je jeszcze przed dojechaniem na odpowiednią stację odpowiedniego release traina. Nie inaczej jest tym razem – Kotlin 1.6.20 to masa dobra o który jeszcze Wam będę opowiadać. Pierwszy milestony już się pojawił, ale tym razem z opisem nowości zdecydowałem się poczekać na jego oficjalną premierę. Dzisiaj jednak wykorzystam okazję pojawienia się świetne opracowania Context Receivers, żeby opisać Wam ten nadchodzący feature języka – inaczej zginie nam w morzu innych nowości, a sam w sobie jest naprawdę interesujący.

W ramach Kotlina dość popularnym konceptem są funkcje rozszerzające (extension functions). Pozwalają one dodać funkcję do hmmm… powiedzieć obiektów byłoby sporym przekłamaniem. Jeśli weźmiemy sobie za przykład:

fun List<Int>.sum():

w tego typu wywołaniu odbiorcą (receiverem) będzie List<Int> – czyli kontener (List) razem z parametrem (Int). Prosto, prawda? To twórcy Kotlina postanowili to nieco utrudnić (ale nie martwcie się, wszystko dla Waszego dobra 😉. Otóż, od tej pory będzie można zdefiniować nie tylko odbiorcę, ale również bardzo precyzyjnie zawęzić kontekst, w którym może on pracować. Popatrzcie na poniższy przykład:

context(Comparator<A>)
fun <A> List<A>.sort(): List<A> = sortedWith(this@Comparator)

O ile w powyższym przypadku .sum() mogło być użyte w całym zdefiniowanym scope (zwykle konkretnym pliku lub module), o tyle powyższe.sort zadziała tylko w kontekście konkretnego komparatora. Żeby to zwizualizować posłużę się przykładem zaczerpniętym ze wspomnianego już artykułu:

with(Comparator.naturalOrder<Int>()) {
  listOf(3, 5, 1).sort()
}

Publikacja poza składnią zawiera też przykłady, gdzie w ogóle tego typu (dość jednak pogmatwana) składania może się przydać. Zapewniam Was, hejterzy języków obiektowych będą w swoim żywiole, Context Receivers da im bowiem jeszcze jedno narzędzie do reużywania kodu bez potrzeby użycia (a tfu) dziedziczenia.

I pewnie nie tylko oni – był to bowiem trzeci najczęściej wybierany przez społeczność dodatek do języka przy okazji poprzedniej ankiety stworzonej przez twórców języka.

A jak już jesteśmy przy Kotlinie, to podrzucę Wam jeszcze jeden, nieco mniej “odjechany” artykuł. Nicolas Fränkel przygotował przegląd funkcjonalności Kotlina, takich które pozwolą nam wykorzystać potęgę jego systemu typów. Ja wiem, tego typu tekstów jest pewnie pół świata i znani bywalcy już pewnie wszystkie triki prezentowane przez autora znają, ale całość jest na tyle zwięzła, że nie mogłem sobie odmówić sobie poświęcenia jej choć akapitu.

1. Społeczność sama pisze dokumentację do JDK Flight Recorder

Źródła

2. Kolejna alternatywa do dziedziczenia w Kotlinie – Context Receivers

Źródła

Odkryj więcej świetnych treści!