JVM Tuesday vol.55 - Java 17 🥳!

1. Java 17 jest z nami 🥳

Mamy to! W dniu dzisiejszym ukazała się w nowa wersja Javy.

Zacznijmy od tych JEPów, które mieliśmy już okazję dla Was opisywać:

O usunięciu Applet API pisaliśmy w naszej edycji 30 tej
Project Lanai i JEP 382 (New Rendering Pipeline) pojawił się w edycji 27
JEP 356 Enhanced Pseudo-Random Number Generators – to vol. 23…
Z kolei w vol 26 opisywaliśmy już JEP-406 Pattern Matching for switch (Preview)
Mocniej Enkapsulowane Internale (JEP-403) to edycja 36
Usunięcie Security Managera gościło u nas już dwukrotnie – w edycji 37 i 38
Trochę naciąganie, ale poruszaliśmy już temat wersji Javy na macOS/ARM w edycji 22
Formalny, zbiorczy post na temat nowej edycji pojawił się w wydaniu 47, przy okazji wersji Release Candidate

Jako, że wspomniane JEPy mamy “odhaczone”, najwyższy czas przypomnieć, że nowa Java to tak zwana wersja Long-Term Support. Sprawia to, że dla wielu firm, które postanowiły nie przechodzić na tryb sześciomiesięcznych wydań, będzie to pierwsza duża edycja od czasu wydanej trzy lata temu Javy 11. Co to oznacza w praktyce? Wiele osób bo raz pierwszy będzie mogło doświadczyć funkcjonalności, które “kapały” sobie przez sześć ostatnich wydań. Ze składniowego punktu widzenia, mowa tutaj o:

Pattern matching for instanceof
Sealed classes and interfaces
Rekordy
Switch Expression
Multiline Strings
Unix-Domain Socket Channels

Wszystkie powyższe to stabilne funkcjonalności.

Oczywiście, żeby wszystkich powyższych używało się wygodnie, nasze narzędzia muszą je wspierać. Dobrze wie o tym JetBrains, który nie ominął okazji, żeby ogrzać się w słoneczku wydania, publikując post pokazujący, jak dobrze Intellij sprawdza się w poszczególnych zastosowaniach. Nawet jeśli śledziliście poszczególne wydania i świetnie wiecie co przynosi Java, i tak polecam lekturę. Podczas przygotowywania autmatycznych refactoringów twórcy najpopularniejszego jvmowego IDE wykazali się bowiem sporą kreatywnością.

Dobra, Java 17 odfajkowana. A już za tydzień będziemy mieli pierwsze informacje o JDK 18 – pojawiają się już konkretne JEPy przeznaczone do tego wydania. Stay Tuned!

PS: Jeśli potrzebujecie pomocy z upgrade, bardzo dobry poradnik przygotowało InfoQ.

Źródło

2. Ron Pressler tłumaczy po co nam w ogóle JPMS 👨‍🏫

My tu informujemy o Javie 17 i co ona przynosi, ale pewnie już łatwo zauważyć, że nawet przeskakując z JDK 8 nie będziemy tu mieli do czynienia z wielką rewolucją jeśli chodzi o to, jak pisze się Javowe aplikacje. Wynika to trochę z faktu, że tak naprawdę największa chyba rewolucja ostatnich lat, czyli JPMS (znany też pod swoją kodową nazwą Jigsaw) nigdy nie została realnie skonsumowana przez ekosystem.

Widać, że twórcom Javy bardzo leży to na sercu, bowiem tekst na temat zalet javowej modularyzacji opublikował niedawno Ron Pressler. Architekt języka pracujący ostatnio głównie nad Project Loom. Postawił on na pracę u podstaw, prezentując ponownie pryncypia stojące za samą ideą javowej modularyzacji, które przez lata (dziewiątka jest z nami już prawie pół dekady) zdążyły gdzieś zginąć. Dlatego też dużo nacisku położone jest w tekście na łatwość zarządzanie classpathem oraz silną enkapsulacje, jaką moduły przynoszą. Ogólnie jeśli kiedykolwiek zastanawialiście się, dlaczego warto zainteresować się modułami – polecam lekturę.

Liczmy na to, że wraz z porzucaniem przez wiele projektów wsparcia dla Javy 8, moduły zaczną się upowszechniać. Myślę, że każdy kto przeczytał artykuł Rona znajdzie dla siebie jakiś dobry powód do migracji.

Każdy nieszczęśliwy codebase jest w końcu nieszczęśliwy na swój własny sposób.

Źródło

What modules are about – Inside.java

3. Jakarta Faces w październiku doczeka się czwartej edycji

A na koniec, po wielkich javowych zapowiedziach – coś ciut hermetycznego Też zapomnieliście że ten projekt istnieje?

Na pewno zapomniała Wikipedia – na ich stronie aktualna edycja to 2.32, pomimo że stabilne 3.0 jest dostępna od października 2020.

Przyznam, że mimo dużej dozy sympatii do Javy EE, Java Server Faces (enigmatycznie mówiąc) nigdy nie należały do moich ulubionych rozwiązań – i mam wrażenie, że nie jestem w tym odosobniony. Koncept cross-warstwowych komponentów brzmi co prawda dobrze na papierze, ale w praktyce wymagał zawsze za dużo “kleju”, a zarządzanie stanem i komunikacja między poszczególnymi elementami UI była zawsze bardzo niewdzięcznym zadaniem. Dodatkowo, przez długi czas takie frameworki jak np. najpopularniejszy chyba PrimeFaces bardzo “lagowały” za światem JavaScriptu. Słyszałem, że sytuacja się nieco pod tym względe polepszyła, ale w międzyczasie społeczność oberwała kolejnym ciosem – Oracle postanowiło przestać rozwijać JSF (wraz z całą Javy EE).

File:Follower of Jheronimus Bosch Christ in Limbo.jpg - Wikimedia Commons — „Limbo Projektowe” Hieronim Bosh

Oczywiście, istnieje gdzieś drugie życie dla wszystkich “porzuconych” – zostają one oddane społeczności. I tak jak Jakarta EE czy JavaFX (o której wydaniu 17 pisaliśmy tydzień temu) także JSFy są ciągle rozwijane pod nazwą Jakarta Faces. Twórcy rozwiązania poinformowali niedawno o planach na wersje czwartą, która ukazać się ma w październiku, wraz z Jakartą EE 10. Lista zmian jest interesująca, gdyż autorzy rozwiązania zdecydowali się skupić na pozbyciu spowalniającego ich balastu. Nareszcie usunięte zostaną stare deprekacje (cześć z nich sięgających jeszcze JSF 2.x). Podjęto też decyzję o pozbyciu się Full State Saving (jeśli chcecie się dowiedzieć więcej o tej funkcji – udało mi się wygrzebać ciekawą publikację na temat zarządzania stanem w JSFach). Oprócz tego, podobnie jak Jakarta EE 10, nowa wersja JSFów to również kolejne kroki w migracji z EJB na CDI.

Jeżeli chcecie sprawdzić nową wersje w praktyce, w Maven Repository znajdziecie pierwszego Milestone’a. Have fun 😇

JVM Tuesday vol.55 – Java 17 🥳!

1. Java 17 jest z nami 🥳

Źródło

2. Ron Pressler tłumaczy po co nam w ogóle JPMS 👨‍🏫

Źródło

3. Jakarta Faces w październiku doczeka się czwartej edycji

Źródło

Odkryj więcej świetnych treści!