W tym tygodniu znowu mamy dla Was możliwość spojrzenia w to, co przyniesie rok 2022… tym razem w dla wsparcia Javy w Visual Studio Code.
Oprócz tego w przeglądzie przeczytacie też o bardzo istotnych zmianach w WildFly oraz pewnym bardzo interesującym Pull Requeście…
Muszę kiedyś przeprowadzić ankietę, ilu z Was używa IntelliJ Idea – moją intuicją jest, że będzie to jednak większość. Dzieje się tak, ponieważ Idea to naprawdę bardzo dobry kawałek oprogramowania, a dodatkowo “odskoczyła” konkurencji na tyle, że dystans wydaje się być niezwykle trudny do nadrobienia. Niektórzy jednak próbują, czego dowodem jest fakt, że od czasu do czasu informujemy Was o nowościach wsparciu dla Javy w Visual Studio Code. W ramach swoich comiesięcznych update, twórcy tego jednak dość ambitnego rozszerzenia zdecydowali się podsumować rok, więc jest to dobra okazja, żeby ocenić na ile rozwój narzędzia daje podstawy do liczenia na realną alternatywę dla kolosa od JetBrains.
Z pewnością highlightem ostatniego roku jest to, że “silnik” całego rozwiązania, tworzone przez RedHata. Rok 2021 przyniósł wsparcie dla Javy 17 oraz znacznie ulepszone nawigowanie po strukturze projektu. Co więcej, znacznie zwiększono wydajność podpowiedzi kodu. Znacznie ulepszono też integrację z zewnętrznymi narzędziami – rozbudowane wsparcie dla Gradle, a GitHubowe CodeSpaces “nauczyły się” obsługi Springa Twórcy chwalą się, że ich rozwiązania spróbowało w zeszłym roku ponad półtora miliona użytkowników, co jest znacznie większą liczbą niż się spodziewałem. Fakt ten mocno mnie cieszy – konkurencja jest korzystnym zjawiskiem. Bez niej pewnie nigdy nie zobaczylibyśmy takiego narzędzia jak JetBrains Fleet.
Smakowicie prezentują się też plany na bieżący rok. Widać, że twórcy starają się wkupić w łaski nie tylko hobbystów, ale też programistów pracujących komercyjnie. Rzeczą, która przyciąga wzrok to szeroko zakrojona “narzędziówka” do Spring Boota, a także dalsze wsparcie dla Gradle i Mavena oraz integracjacja z Kubernetesem. Oprócz tego należy się spodziewać dalszych ulepszeń w aspekcie User Experience – w tym kontekście szczególnie wybija się Live Share, który wybija się na jedną z bardziej istotnych w dobie pracy zdalnej funkcjonalności VSCode. Twórcy obiecują też bardziej inteligentne podpowiadanie kodu oraz wygodniejsze doświadczenie debugowania.
Kolejna informacja dotyczy WildFly. Jednocześnie ze względu na to, jak mocno idzie pod prąd ostatnim “standardom”, jeśli chodzi o sposób releasowania oprogramowania, powinna być interesująca dla nieco szerszej rzeszy ludzi niż typowe ogłoszenia związane z Javą EE.
Otóż w dobie, gdy większość projektów przechodzi na regularny “pociąg releasowy”, WildFly zdecydował się na swoisty krok w tył i oparcie swoich nowych wersji o zdefiniowane zbiory funkcjonalności. Najnowsze wydanie będzie wydane dopiero wtedy, kiedy ukaże standard Jakarty EE 10 i serwer będzie na to gotowy. Jest to swoisty powrót do korzeni, gdy nowe wydania serwerów aplikacyjnych były znacznie rzadsze i wiązały się właśnie z dużymi podbiciami standardu, nie konkretnymi datami w kalendarzu.
Dobrze, ale co poza nową wersją Jakarty EE przyniesie wydanie WildFly 27? Kolejny cios w stronę Javy 8 – WildFly 26.1 będzie ostatnim wydaniem które będzie wspierało wciąż najpopularniejszą edycję Javy. Co ciekawe, to nie jedyna “ósemka”, która zostanie porzucona wraz z nowym wydaniem – twórcy serwera aplikacyjnego pozbywają się także wsparcia Javy EE 8. Oznacza to, że WildFly 27 będzie pierwszym wydaniem zupełnie pozbawionym brandingu Javy (i “robaczywych” zależności na pakiety javax.*) . Jest to więc rzeczywiście duży krok nie tylko dla frameworku, ale dla całej społeczności Jakarty.
Jeżeli chodzi o inne “porzucone” funkcjonalności, to jest ich znacznie więcej. WildFly 27 nie będzie wspierał również MicroProfile w wersji 4 (jako, że ten opierał się jeszcze na wspomnianym javax.*), jak i Log4j (aczkolwiek w wersji pierwszej, nie tej będącej gwiazdą grudniowych nagłówków). Jak więc widać, WildFly 27 będzie do tego stopnia odchudzony, że możemy uznać nowe wydanie za istotny kamień milowy w życiu tego najbardziej “żwawego” serwera aplikacyjnego.
A na koniec informacja o pewnym bardzo interesującym Pull Requeście w repozytorium JDK.
Tydzień temu prezentowaliśmy Wam przegląd tego, czego można spodziewać się po roku 2022, jeśli chodzi o duże Javowe projekty. Nie spodziewałem się jednak, że tak szybko będziemy mieli dla Was dalsze ogłoszenia. Jak bowiem donoszą użytkownicy Reddita, Projekt Panama wychodzi z inkubacji – stosowna repakietyzacja pojawiła się już w kodzie, teraz przyszedł czas na merge do brancha openjdk:foreign-preview. Oznacza to, że już niedługo powinniśmy zobaczyć je jako Preview (przyznam, że nie jestem pewien czy ma szansę załapać się jeszcze na JDK 18, ale postaram się to potwierdzić).
Jeśli kiedykolwiek byliście ciekawi, jak wygląda “żywa” praca nad Javą (w tym jak wygląda review takiego kodu), potraktujcie oryginalny PR jako “zasób edukacyjny”, ponieważ sama zmiana jest wyjątkowo klarowna i łatwa do zrozumienia jak na standardy repo JDK.
