Niedawno zobaczyłem gdzieś w mediach społecznościowych fragment kodu. Jak mniemam, miał pokazać, że “Java jest zła i martwa”. Myślę, że to dobry moment, żeby przyjrzeć się niektórym twierdzeniom, nieprawdom i półprawdom, które pojawiły się w komentarzach i nie powiem, nawet mnie rozbawiły. Przy okazji odpowiem na część zarzutów, które padły podczas kilku wykładów konferencyjnych jesienią (sprawdza kalendarz) 2026 roku!

TL;DR: kompaktowe pliki źródłowe już są z nami, obiekty value z Valhalli nadchodzą, możesz nadal tkwić mentalnie w 2005 roku, ale miej świadomość, który rok mamy teraz.

Zanim zacząłem pracować na pełen gwizdek jako developer advocate, nie spotkałem się z terminem BBL. Oczywiście samo przeczytanie tytułu tego wpisu zadaje kłam insynuacjom pewnych złośliwców, że jest to wyłącznie termin medyczny. Okazuje się, że niekoniecznie ;-)

Zatem: co to jest i co to nie jest ten BBL?

Gdybym dostawał jednego dolara za każdym razem, gdy słyszę “musieliśmy wyłączyć security i uwierzytelnianie w Elasticsearch, bo inaczej nie dało się z tego korzystać”, to byłbym już parę dolarów do przodu ;-)

Prawdę mówiąc, to nie bardzo rozumiem, skąd bierze się to zamieszanie. Mamy 2024 rok, jednak niektórzy z nas są wciąż zaskoczeni przez “ale jak to certyfikat i hasło???”

Pozwólcie mi w paru prostych akapitach wyjaśnić temat security w Elasticserchu.

Java 22 zostanie wydana jutro. W tej wersji jest wiele super rzeczy. Podejrzewam, że korzystanie z wywołań rodzimych/zewnętrznych w projekcie Panama sprawi, że życie wielu osób stanie się łatwiejsze, jak również trwające zmiany we współbieżności, szablonach napisów i wreszcie możliwość wywołania czegoś przed super. Super! Jednak jest jedna rzecz, która podejrzewam stanie się moim (prawie) ukrytym bohaterem Javy 22. Ludziska, przedstawiam wam Gatherers.mapConcurrent!

Strumienie są bohaterem Javy 8 (ale nie w świecie równoległym)

Java 8 była dużym kamieniem milowym w rewolucji Javy w swoim czasie. Pamiętam atmosferę po stosunkowo niewielkim wydaniu Javy 7, wersja 8 była NAPRAWDĘ WIELKA. Wprowadzenie lambd pozwoliło Stream API na istnienie w Javie 8 (bez krwawiących oczu, oczywiście). Moim zdaniem skierowało to Javę w stronę deklaratywnego i funkcyjnego sposobu myślenia o przetwarzaniu danych: zamiast pętli z pośrednimi wywołaniami i pakowania wyników w pojedynczy obiekt, mogliśmy wreszcie wyrazić intencję w bardziej deklaratywny sposób.

Poprzednio umieściłem na moim blogu dwa wpisy. Jeden dotyczył Java skryptów, drugi możliwości ich przenoszenia poprzez wykorzystanie shebang.

O ile mogę stwierdzić, wszystko w tych dwóch częściach nadal jest aktualne, jednak teraz, w Javie 21, dzięki JEP-445, poprzednie dwa wpisy mogłyby być jeszcze bardziej zwięzłe. W tym wpisie spróbuję opisać najpierw zmiany wprowadzone przez ten JEP, a następnie zajmę się bardziej szczegółowo tym, w jaki sposób mają się do “skryptów w Javie”.

Opiszę, jak można uprościć metodę main, pozbyć się otaczającej jej klasy, a potem zobaczymy, kiedy to nie będzie działać.

Jak napisałem w moim poprzednim wpisie, miałem problemy z uruchomieniem kodu wykorzystującego JEP 443 przy użyciu narzędzi takich jak Maven, Gradle czy IntelliJ IDEA. Dzięki jedynemu i niezastąpionemu Tagirowi Waljejewowi, rozwiązanie jest dość proste.

Zaktualizuj JDK do 21.0.1.

I to by było na tyle ;-)

Nie ma potrzeby tykania niczego innego. Jeśli masz ochotę na więcej wyjaśnień, proszę rzuć okiem na ten wątek na Twitterze.

I wszyscy będziemy pamiętać, że aktualizacja to dobra rzecz, bo przecież nie zostaniemy na zawsze przy Javie 8, prawda? ;-)

Update

Sprawa została rozwiązana, polecam przeczytać wpis z rozwiązaniem.

Notatka: Poniżej pozostawiam oryginalny wpis na wypadek, gdyby ktoś jednak napotkał w przyszłości podobny problem. Czasem łatwiej szukać po problemie ;-)

Podczas przygotowywania demek do wykładu co tam w Javie 21 piszczy dla zaprzyjaźnionych JUGów, natknąłem się na ciekawy przypadek JEP 443: Unnamed Patterns and Variables (Preview). Udało się go wydestylować i zreplikować.

Przygotowywałem prosty przykład dla tego JEPa. Jest on oczywiście bardzo przydatny (JEP, przykład mniej) i na pewno poprawi możliwości Javy do wyróżniania się w scenariuszach programowania zorientowanych na przetważanie na danych.

Pozwólcie mi rozpocząć ten wpis od suchara.

Jedzie sobie elektron na motorze. Nagle zatrzymuje go policjant i mówi:

“Musiałem Pana zatrzymać, bo przekroczył Pan znacznie prędkość, jadąc dokładnie 178 i pół kilometra na godzinę.”

“No WIELKIE DZIĘKI, panie policjancie. To teraz kompletnie nie wiem, gdzie jestem!”

Niektóre suchary są niesamowicie słabe, więc nie martw się, jeśli ten Cię nie rozbawił. Ten sprowadza się to do zasady nieoznaczoności. W niezwykle uproszczonym ujęciu: niektóre rzeczy we wszechświecie nie mogą być obserwowane we wszystkich swoich aspektach. Jeśli masz jabłko, możesz zmierzyć jego masę, objętość, rozmiar (i jeśli spadnie Ci na głowę) prędkość, wszystko jednocześnie. Bez wpływu na samo jabłko. Jednak jeśli interesują Cię elektrony, im dokładniej znasz ich prędkość, tym mniej wiesz o ich położeniu, i odwrotnie, stąd chmura elektronowa. (Do licha, czy rzeczy atomowe przestaną mnie ścigać? 😅)

Nie zawsze prowadzę publiczne szkolenia otwarte, ale gdy tak robię, to staram się, aby miały one charakter charytatywny. Uważam, że ta formuła ma wiele sensu. W tym wpisie postaram się pokazać, dlaczego uważam ją za użyteczną i potrzebną, ale pozwólcie, że zacznę od kilku zasad.

Jeśli podoba ci się ten pomysł, śmiało możesz go wykorzystać.

Zasady

Gdy prowadzę charytatywne warsztaty z dziedziny IT, wprowadzam następujące zasady. Ważne jest ich pełne przestrzeganie, ponieważ złamanie jednej z zasad może całkowicie wypaczyć sens pozostałych.