Wybór języka

Java

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.

Do tej pory prezentacja była wygłaszana wyłącznie po angielsku. Chętnych na wersję polską zapraszam do kontaktu ;-)

Streams were a very nice addition to Java 8, based on lambdas. They allow streamlined data processing without side effects, taking us gently towards functional style. With newer additions to Java, like records and pattern matching, they shine even more in data-driven flows. However, they don’t come without flaws. For starters, the only available extension point was collectors: if your needs for gathering data weren’t satisfied by the whole Collectors ZOO, you could always fall back to creating your own Collector. However, if map, filter or flatMap weren’t enough, you couldn’t add your own intermediate operation. Secondly, parallel streams were limited to ForkJoin pool, effectively rendering them unusable for scenarios involving any IO. Since Java 22, Stream Gatherers are our extension point for intermediate operations in streams. If you’d like to comprehend how they work, find nice use cases and hunt for more performance, this talk is for you.

Do tej pory prezentacja była wygłaszana tylko po angielsku. Jeśli ktoś byłby chętny na wersję po polsku, to zapraszam do kontaktu ;-)

Integration tests are nice. We all know that and love using them, don’t we? It’s just using all those databases, message brokers and other things as real dependencies, only wrapped by Testcontainers, might result in a really heavy CI/CD pipeline and developers’ attitude to never run them locally, because they’re so slooooooooooow. What if I could show you a number of techniques, mindset changes and tricks to get your integration tests shortened from quarters to seconds? Would that be interesting for you, to benefit from the confidence integrations tests give you, before you’re able to brew a fresh coffee? It’s really not about re-inventing the wheel, but using it the smart way.

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.

Wykład odbył się jak na razie tylko raz i tylko dla Silesia JUG w Katowicach, po angielsku. Chętnych na wersję polską zapraszam do kontaktu:

Let’s talk about Java 21 and have a sneak-peek into Java 22, and things like: Java was supposed “to be slow”. However, Java turns out to evolve so fast, that next releases aren’t just version bumps, but might significantly change the rules of the game. That’s a good reason to check out what’s new in Java. To name a few changes:

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.

Java™ 21 is real now. And so are virtual threads. Everyone got excited about them, yet you prefer to keep your Java 8 job forever, and you already have a nice plan to “accidentally” derail the migration to 21 by using virtual threads in a very, very unfortunate way. What a pity…

So you decided to come for this talk to look for some inspiration ;-)

Okay, please join us to learn how NOT to use virtual threads, and see the potential performance pitfalls of using them the wrong way.