1. JetBrains umożliwia testowanie K2 Mode in IntelliJ Idea
Zaczniemy od dużego newsu od JetBrainsów. Od wersji 2024.1 (którą posiadacze subskrypcji Ultimate mogą testować), ich sztandarowej IntelliJ IDEA oferuje opcjonalny tryb K2. IDE posiadać będzie teraz więc dwa oddzielne tryby: klasyczny (domyślnie włączony), gdzie do analizy kodu używany jest standardowy kompilator Kotlin (dla Kotlina 1.x), oraz tryb K2, gdzie do analizy kodu wykorzystywany jest nowy kompilator K2 pochodząc Kotlina 2.0. Jako, że K2 został de facto napisany od nowa, włączenie jego trybu w IDE ma przynieść nie tylko poprawę wydajności i ulepszenia wewnętrznej architektury toolingu, ale też zapewnia zgodność z przyszłymi funkcjami Kotlin. Wsparcie dla trybu K2 w IntelliJ IDEA 2024.1 obejmuje podświetlanie i uzupełnianie kodu, nawigację, wyszukiwanie użycia, debugowanie, refaktoryzację oraz podstawowe funkcje edycji.
Żeby lepiej wybrzmiało: tryb K2 te dotyczą tylko analizy kodu w IDE i nie zależy od wersji kompilatora Kotlin określonej w ustawieniach budowania projektu. Aby skompilować projekt przy użyciu kompilatora K2, nadal należy to określić w ustawieniach budowania projektu. W trybie K2 nie są jeszcze wspierane projekty Kotlin Multiplatform, projekty Android, niektóre rodzaje refaktoryzacji i narzędzia debugowania oraz analiza kodu w plikach .gradle.kts, a także inne drobne funkcje. Wsparcie dla brakujących funkcji zostanie dodane w nadchodzących wydaniach.
To jednak nie wszystko z nowości, bowiem JetBrains podzieliło się też planami na rozwój ich sztandarowego Kotlinowego Frameworki, Ktor. Ten w 2024 roku, planuje wprowadzić masę nowości nowości i ulepszeń, w tym wtyczkę OpenTelemetry, która umożliwi generowanie danych telemetrycznych, takich jak metryki, logi i ogólny tracing. Dodatkowo, pojawi się integracja gRPC z klientem i serwerem Ktor za pomocą idiomatycznej implementacji Kotlin, co ułatwi tworzenie i korzystanie z usług opartych na gRPC. Spodziewać możemy się też zarządzania transakcjami za pomocą oficjalnej wtyczki, która będzie inicjować transakcję na początku żądania i zatwierdzać ją na jego końcu, o ile nie wystąpią błędy, upraszczając tym samym dostęp do bazy danych. Zapowiedziano też wsparcie dla nowej implementacji IO – Kotlinx-io, która już Ktor 3.0.0 zastąpi istniejące rozwiązanie. Kotlinx-io bazuje na Okio i jest rozwiązaniem multiplatformowny, co ułatwi twórcom bibliotek wsparcie Ktora. Planowane jest też wprowadzenie rejestru wtyczek, umożliwiającego rejestrowanie pluginów tworzonych przez społeczność.
Ostatnią nowością oryginalnego tekstu jest zapowiedź uproszczenia wstrzykiwania zależności (Dependency Injection) poprzez oficjalne dodanie wsparcia dla DI do serwera Ktor w 2024 roku oraz publikację wytycznych, jak najlepiej integrować istniejące biblioteki DI. Ktor zostanie zmodyfikowany, aby wspierać DI oraz integrować istniejące frameworki DI. Ta zapowiedź wywołała masę kontrowersji, do tego stopnia, że twórcy musieli opublikować followup, w którym podkreślili że korzystanie w Ktor z frameworka DI nigdy nie będzie wymagane, a sam Ktor nigdy nie będzie zawierał wbudowanego frameworka DI jako części swojego projektu. Zaproponowana funkcjonalność przeznaczona będzie wyłącznie dla użytkowników, którzy chcą połączyć DI ze swoimi usługami Ktor, a ma na celu jak najbardziej płynną integrację istniejących frameworków DI z frameworkiem.
A jak już jesteś w temacie Dependency Injection to Helidon zapowiedział nową funkcje, będącą ich własnym podejściem do dependency injection opartym o standard JSR-330:Dependency Injection for Java. Rdzeniem Helidon Injection, bo o niej tu mowa, jest annotation processor, który wyszukuje w kodzie aplikacji standardowe adnotację jakarta/javax. Gdy takie adnotacje są znalezione w klasie, Helidon Injection inicjuje tworzenie tak zwanego Aktywatora dla danej klasy/usługi, zarządzającego jej lifecycle. Na przykład, obecność adnotacji @Inject lub @Singleton w klasie FooImpl powoduje utworzenie FooImpl.injectionActivator, agregujący usługi dla danego modułu, co pozwala na ich zarejestrowanie w „rejestrze usług” (który tak naprawdę sam w sobie jest klasą wygenerowaną przez Annotation Processor), a co za tym idzie późniejsze łatwe odnalezienie i inicjalizacji.
Generated(value = "io.helidon.inject.tools.creator.impl.DefaultActivatorCreator", comments = "version = 1")
@Singleton @Named(Injection$Module.NAME)
public class Injection$Module implements Module {
static final String NAME = "inject.examples.logger.common";
@Override
public void configure(ServiceBinder binder) {
binder.bind(io.helidon.inject.examples.logger.common.AnotherCommunicationMode$injectionActivator.INSTANCE);
binder.bind(io.helidon.inject.examples.logger.common.Communication$injectionActivator.INSTANCE);
binder.bind(io.helidon.inject.examples.logger.common.DefaultCommunicator$injectionActivator.INSTANCE);
}
}
Takie podejście umożliwia też zapewnienie „leniwego” aktywowania usług na podstawie bieżące zapotrzebowania konkretnej aplikacji – konkretna usługa może pozostać uśpiona do momentu gdy jest potrzebna, co oczywiście wiąże się z lepszym efektywne wykorzystanie zasobów i poprawę wydajności aplikacji. Wprowadza też możliwość rozległych integracji i rozszerzalności – Helidon Injection pozwala min. na generowanie kodu obsługi interceptorów poprzez meta-adnotacje InterceptedTrigger.
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Kilka follow-upów do JDK 22
Temat premiery JDK 22 nie ucicha, bo jak zwykle tego typu wydaniu towarzyszy kilka publikacji od społeczności. Dlatego mam dzisiaj dla was dwie, nieco jako follow-up do zeszłotygodniowego edycji.
Zacznijmy od publikacji Seana Mullana, który to jak zwykle podzielił się z nami nowościami dotyczącymi bezpieczeństwa. Nie ma tutaj jakichś rewolucyjnych zmian – wśród głównych nowości znajdują się dodanie kilku nowych certyfikatów root CA, wprowadzenia interfejsu java.security.AsymmetricKey, ulepszenia wsparcia dla algorytmów podpisów RSA w wersji XML z użyciem skrótów SHA-3, a także wsparcia dla algorytmu podpisu HSS/LMS w narzędziach keytool i jarsigner. Ponadto, JDK 22 ułatwia zarządzanie maksymalną długością łańcuchów certyfikatów TLS dla klienta i serwera poprzez nowe propertiesy systemowe.
Przejdźmy do kwestii wydajności. Drugim tekstem, który przykuł moją uwagę to publikacja How fast is Java 22? od Lukáša Petrovickiegoz timefold.ai, projektu zajmującego się szeroko rozumianym schedulingiem dla biznesu, jak np. zmiany pracowników czy rezerwacje pojazdów. Sercem projektu jest silnik Timefold Solver, który odpowiada za jego główną logikę i to właśnie jego Lukáš użył do przetestowania wydajności JDK 22 oraz GraalVM for JDK 22. Testy miały na celu sprawdzenie, czy kod Timefold Solver nadal działa bezproblemowo na Java 22 i czy wydajność jest przynajmniej taka sama jak wcześniej. Jak to zwykle bywa z benachmarkami, należy patrzeć na nie z lekkim przymróżeniem oka, ale Lukáš robił je na swoje własne potrzeby, więc spodziewam się, że do tematu podszedł bez uprzedzeń, z należytą rzetelnością.
W wynikach microbenchmarków (wykonanych z użyciem Java Microbenchmark Harness, JMH) oraz testów w realnych warunkach zauważono, że wydajność OpenJDK 22 w porównaniu z Java 21 jest niezmieniona, z wyjątkiem jednego testu, który wymagał dalszej analizy. Natomiast GraalVM dla JDK 22 (nawet bez użycia natywnych obrazów) wykazał znaczącą poprawę wydajności, średnio o około 5% i maksymalnie o około 15% w określonych benchmarkach, co czyni go atrakcyjną opcją dla aplikacji korzystających z Timefold Solver. Wyniki te wskazują, że przejście na Java 22 nie wpłynie na zmiany w wydajności, jednak użycie GraalVM dla JDK 22 może przynieść znaczące ulepszenia wydajności do 10%. Co ciekawe, wbrew ogólnym trendom, twórcy Timefold.ai opierają się na klasycznym ParallelGC zamiast domyślnego G1 ze względu na jego lepszą wydajność w przetwarzaniu, nie zaś opóźnieniach.
No cóż powiem, kolejne punkty dla GraalVM.
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Release Radar
Java Mission Control 9.0
Dla tych którzy nie kojarzą projektu, Java Mission Control (JMC) to narzędzie do monitorowania, zarządzania i profilowania aplikacji Java, którego założeniem jest brak wprowadzanie znaczących opóźnień czasowych w działaniu aplikacji, co sprawia, że łatwiej jest zracjonalizować decyzje uruchomienia go w środowisku produkcyjnym. Dzięki integracji z JDK, JMC oferuje dostęp do bogatej gamy danych o wydajności i zachowaniu aplikacji Java poprzez analizę rekordów Java Flight Recorder (JFR), umożliwia użytkownikom zarówno zbieranie danych o wydajności w czasie rzeczywistym oraz przeglądanie i analizowanie danych historycznych.
W zeszłym tygodniu wydano JDK Mission Control 9.0, która do działania wymaga minimum poprzedniego LTS, czyli JDK 17, przy równoczesnym wsparciu dla analizy zapisów JFR jeszcze z wersji JDK 7u40+ (kompatybilność Javy nie przestaje na mnie robić wrażenia). JMC 9 ciemny motyw (dla wszystkich nocnych marków) wprowadza kompatybilność z Eclipse 4.30, wsparcie dla Linux aarch64, a także usprawnienia w parserze JFR i reorganizację klasy, umożliwiając lepszą integrację z aplikacjami stron trzecich. Znaczące zmiany obejmują również nowe reguły oceny wydajności i wykorzystania zasobów, ulepszoną wizualizację w postaci Java-based flamegraph oraz eliminację wtyczki Twitter (zaskoczyło mnie, że taka w ogóle istniała) ze względu na zmiany w API i koszty utrzymania.
Gradle 8.7
Gradle 8.7 wprowadzono szereg usprawnień i nowości, w tym wsparcie dla projektów korzystających z Java 22, choć co ciekawe, samo Gradle 8.7 jeszcze nie działana tej wersji Javy ze względu na brak jej wsparcia w Groomym.
Jeśli chodzi o funkcjonalnością, nowością jest usprawnienie wykorzystania lokalnego lub zdalnego bufora budowy dla kompilacji skryptów Groovy, co pozwala na uniknięcie ponownej kompilacji i redukcję czasu pierwszego budowania projektu. Wprowadzono również lepsze API do aktualizacji właściwości kolekcji oraz usprawnienia w raportowaniu błędów i ostrzeżeń, co ułatwia identyfikację i rozwiązywanie problemów związanych min. z wtyczkami. Reszta zmian dotyczą ulepszeń w konfiguracji cache, wprowadzenia nowych funkcji w Kotlin DSL (w tym aktualizacje do Kotlin 1.9.22), oraz usprawnień w obsłudze TestNG i zarządzaniu symlinkami w systemie plików.
Apache Pekko zostaje Top Level Project Apache Foundation
Apache Pekko powstało jako alternatywa dla popularnego frameworka Akka, który jest szeroko stosowany do tworzenia reaktywnych aplikacji w języku Scala i Java. Inspiracją do stworzenia Apache Pekko była również zmiana licencji Akka, co spowodowało niepewność wśród społeczności programistów co do przyszłego dostępu i wykorzystania tego frameworka w projektach komercyjnych. Głównym celem powstania Apache Pekko było zaoferowanie podobnej funkcjonalności co Akka, ale pod egidą Apache Software Foundation, co gwarantuje otwartość i dostępność projektu dla szerszego grona deweloperów. Teraz projekt otrzymał status Top Level Project.
Uzyskanie statusu Top Level Project (TLP) przez Apache Pekko jest potwierdzeniem jego wartości i stabilności jako narzędzia do tworzenia aplikacji reaktywnych. Status TLP w ekosystemie Apache Software Foundation (ASF) oznacza, że projekt przeszedł kompleksowy proces inkubacji, wykazując swoją żywotność, zdolność do samodzielnej ewolucji i utrzymania aktywnej społeczności. Dla Apache Pekko, bycie TLP to nie tylko prestiż i uznanie w środowisku open-source, ale także większa niezależność i możliwości rozwoju. Projekt może teraz korzystać z pełnego wsparcia fundacji, zarządzając własną infrastrukturą, procesami i zasadami, co umacnia jego pozycję jako kluczowego narzędzia dla programistów poszukujących alternatywy dla Akka w budowie wydajnych i skalowalnych aplikacji reaktywnych.
