Dzisiaj dosyć różnorodnie. Oracle zaczęło przyznawać się do Jakarty EE 10, a Eclipse przyjmuje AdoptOpenJDK pod swoje skrzydła. Oprócz tego mamy dla Was też małą dramę ze środowiska Scalowego. Zapraszamy do lektury!
1. Co nowego przyniesie Jakarta EE 10
Zacznijmy od radosnej nowiny! Niekochane dziecko zyskało atencje i uwagę rodzica!
Nie wiem, jak inaczej można określić bowiem fakt, że Oracle na oficjalnym blogu Java Magazine opublikował zapowiedź Jakarty EE w wersji 10. Wprawdzie tagline artykułu: “The release is only a year away. Here’s what to expect.” przenosi nas w nieco inny czas, gdy wszystko działo się… wolniej, ale w dalszym ciągu już dziś warto przyglądnąć się, co też nowego ujawni nowa edycja standardu.
Motywem przewodnim całego wydania jest posprzątanie bałaganu (żeby nie użyć mocniejszego wyrażenia), którym jest wstrzykiwanie zależności w wersji EE. Przez lata żyliśmy z niejako “legacy” Enterprise Java Beans, która ewoluując wraz z całą platformą, nie chcąc łamać wstecznej kompatybilności, obrastały nowymi możliwościami do poziomu, gdy stały się wręcz nieużywalne.
W grudniu 2009 na rynek trafiła Java EE 6, która wprowadziła nowość – CDI API (Contexts and Dependency Injection), będące lekką alternatywą do EJB. Standard ten okazał się być na tyle udany, że przez krótki czas (zanim pojawił się Spring Boot i pozamiatał) wiele osób wróżyło Javie EE zwycięstwo nad Springiem. Niestety, dziedzictwo nie dało o sobie zapomnieć. CDI nie były kompatybilne z wieloma standardami Javy EE, w tym jednym z najważniejszych takich jak np. @Asynchronous. Dopiero teraz, wraz z Jakartą EE 10, sytuacja ulec ma zmianie.
CDI ma być wspierany przez wszystkie najważniejsze API, w tym Concurrency (w którego skład wchodzi właśnie @Asynchronous), Jakarta Server Faces czy też Servlet API. Jeżeli interesują Was szczegóły techniczne, artykuł od Oracle jest bardzo interesujący. Opisuje on bowiem problemy, jakie stoją na drodze modernizacji wspomnianych API, zarówno po stronie projektantów teraz, jak i vendorów w przyszłości – co jest równie istotne, biorąc pod uwagę jak powoli trwają prace nad implementacją Jakarty EE 9 w popularnych serwerach aplikacyjnych.
A tymczasem, fani “edycji dla przedsiębiorstw” powinni oczekiwać Jakarty EE 9.1, która tuż tuż (według tabelki – Q2 2021). Przyniesie ona długo wyczekiwane wsparcie dla JDK 11.
Źródła:
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
2. AdoptOpenJDK zmienia się w Adoptium i trafia pod skrzydła Eclipse
Ciągnąc wątek projektów oddanych przez Oracle społeczności warto wspolnieć oAdoptOpenJDK, projekcie, który powstał jako efekt wysiłków społeczności walczącej o “wolną” implementacje JDK, ostatecznie trafia on pod skrzydła Eclipse Foundation. Efekt ponad rocznych starań kwituje przechrzczenie projektu na Eclipse Adoptium (JDK jest znakiem towarowym należącym do Oracle) oraz powstanie Adoptium Working Group.
Biorąc pod uwagę fakt, że Oracle obecnie udziela wyłącznie sześciu miesięcy wsparcia, dla każdego nowego wydania, Adoptium jest krytycznym projektem dla całej społeczności, nie tylko Javy, ale również innych JVMowych języków. Cały projekt fundowany jest przez mnogość partnerów – Alibaba Cloud, Huawei, IBM, iJUG (stowarzyszenie niemieckich JUGów), Karakun AG, Microsoft, New Relic oraz Red Hat będą brać udział w rozwoju otwartej wersji Javy. W ramach negocjacji udało się też otrzymać dostęp do Javowego Technology Compatibility Kit, “wywalczonego” od Oracle.
Jeżeli chcecie śledzić rozwój Adoptium, oryginalny link zawiera zbiór stron, kont społecznościowych i repozytoriów, które również przeszły rebranding. My na pewno nie pozwolimy przegapić Wam wszelkich ważnych ogłoszeń.
Źródła:
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Jak trudne jest “utrzymanie” projektu w Scali? Społeczność dyskutuje
A na koniec – Scala, której Release Party wersji 3.0 już 23 kwietnia.
W przededniu tego bardzo znaczącego dla społeczności wydarzenia, w sieci dość mocnym echem odbił się artykuł krytykujący to, jak nieprzyjazna dla programistów jest druga edycja tego języka. Dla tych, którzy nigdy nie mieli styczności z tym językiem – każde “minorowe” wydanie Scali nie jest tak naprawdę “minorowe”. Scala używa numeracji epoch.major.minor, co oznacza że zmiana z 2.12 na 2.13 łamie kompatybilność (poszczególne wydania nie są wstecznie kompatybilne). Autor oryginalnego tekstu wskazuje, że jeśli dodamy do tego tempo wypuszczania nowych edycji (mniej więcej jedna do roku), całość staje się naprawdę nieprzyjemna w utrzymywaniu.
Fakt, że każdorazowo trzeba przepisać (a przynajmniej zrekompilować) cały ekosystemem bibliotek, wiele z libek nigdy nie uzyskuje wsparcia dla nowych wersji. Prowadzi do smutnej sytuacji, gdy projekty muszą tkwić w archaicznej wersji Scali, ze względu na brak wsparcia którejś z ważnych zależności. Co ciekawe, problem występuje też od drugiej strony. Czasem to stare projekty, nie mogące się zaktualizować, mają pod górkę – bardzo szybko tracą wsparcie np. łatek bezpieczeństwa, ponieważ autorzy bibliotek zbyt szybko przerzucają się na nową wersję języka, nie patrząc wstecz. Autor postu wskazuje też na problemy związane z dynamicznym rozwojem SBT.
W komentarzach i w popularnych agregatorach nie brakuje jednak ludzi, którzy uważają argumenty autora za mocno rozdmuchane. Nie brakuje jednak osób, które popierają zawarte w poście twierdzenia, dyskusja jest więc dość zażarta, choćby na redditcie.
Niedługo przekonamy się, jak społeczność przyjmie przejście ze Scali 2.13 na Scalę 3. Według Scala Center, Scala 3 ma być w dużym stopniu kompatybilna z ostatnim wydaniem wersji 2. Pozostałe niekompatybilności rozwiązać ma zaś narzędzie migracyjne, które zostało wydane w zeszłym tygodniu. Na pewno obserwować będziemy, jak społeczność przyjmie długo oczekiwanego “Dotty’ego”
PS: Jeżeli macie problem, o którym wspomina autor posta, Fury obiecuje rozwiązywać większość z nich. John Pretty, autor biblioteki, w bardzo interesujący sposób opowiada o powodach jej powstania na różnych meetupach, opisując jak zamierza poradzić sobie z problemami, o których była mowa..
Źródła:
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
