1. Scala 3 nareszcie wydana! 馃コ

Zacznijmy od zdecydowanie najwa偶niejszego wydarzenia zesz艂ego tygodnia.

Cytuj膮c oryginalnych autor贸w: po 8 latach pracy, 28 tysi膮cach commit贸w, 7400 Pull Requestach oraz ponad 4000 zamkni臋tych issuesach - Scala 3 nareszcie jest z nami! Przez kr贸tk膮 chwil臋 istnia艂o ryzyko, 偶e czeka nas jeszcze jedna wersja Release Candidate, ale wszystkie krytyczne b艂臋dy uda艂o si臋 zamkn膮膰 przed docelowym terminem. Czternastego maja (a w艂a艣ciwie jeszcze trzynastego w nocy - mamy nadziej臋, 偶e to nie b臋dzie pechowe) nowa wersja zosta艂a opublikowana.

Pozwol臋 sobie troch臋 oszuka膰, i zamiast robi膰 pe艂ny przegl膮d nowych mo偶liwo艣ci, podlinkuje do rozmowy z naszym lokalnym firmowym specjalist膮, kt贸r膮 mia艂em kiedy艣 okazj臋 przeprowadzi膰 - poza ko艅c贸wk膮, gdzie ci膮gle jeszcze si臋 艂udzimy, 偶e Scala 3.0 b臋dzie gwiazdkowym prezentem, nie zestarza艂a si臋 za bardzo:

Opublikowano te偶 informacje na temat przysz艂ego cyklu releasowego. Nowe wydania patch (3.0.x) Scali maj膮 ukazywa膰 si臋 regularnie, co sze艣膰 tygodni.

Obiecano r贸wnie偶, 偶e szczeg贸lna uwaga b臋dzie po艣wi臋cona wstecznej kompatybilno艣ci, co przez lata by艂o pi臋t膮 achillesow膮 Scali. Pozwoli膰 ma na to nowy format po艣redni binarek, o smakowitej nazwie TASTy. Na ten moment tw贸rcy podaj膮, 偶e 308 bibliotek (ze wszystkich 2597 dost臋pnych dla wersji 2.13) chwali si臋 pe艂n膮 kompatybilno艣ci膮 ze wersj膮 3.0.

No c贸偶, 偶yczymy Scali, 偶eby to wydanie by艂o dla niej drug膮 m艂odo艣ci膮 馃コ

Nie wszystkim j臋zykom uda艂o si臋 to bezbole艣nie

殴r贸d艂a:

2. Czy wiesz czym r贸偶ni si臋 Jakarta EE od Microprofile ? 馃槒

Je偶eli kto艣 robi艂by list臋 najbardziej myl膮cych dla programist贸w aspekt贸w Javowego ekosystemu, jestem przekonany, 偶e relacja mi臋dzy Jakart膮 EE i Microprofilem by艂aby jedn膮 znajduj膮cych si臋 na samym szczycie. Nie do艣膰, 偶e tak naprawd臋 wi臋kszo艣膰 os贸b pracuj膮cych z Java EE, zatrzyma艂y si臋 na edycjach Java EE 5/6 - nie bez winy s膮 tutaj wolno rozwijaj膮ce si臋 serwery aplikacyjne i kontrowersje, kt贸rymi od samego pocz膮tku otoczona by艂a Jakarta EE. Oliwy do ognia doda艂 te偶 fakt, 偶e pojawienie si臋 Microprofilu (b臋d膮cego dodatkowym, niezale偶nym od g艂贸wnej specyfikacji wycinkiem, przeznaczonym do zastosowa艅 mikroserwisowych) by艂o motywowane nieco przestarza艂ym sposobem dystrybucji serwer贸w aplikacyjnych, nie realnymi potrzebami rynku.

Na szcz臋艣cie tw贸rcy Jakarty EE oraz MicroProfilu poszli po rozum do g艂owy i zaczynaj膮 interesuj膮ce ruchy w celu posprz膮tania tego ca艂ego bajzlu. Pocz膮tkiem roku powsta艂o The Cloud Native for Java (CN4J) Alliance, w sk艂ad kt贸rego wchodz膮 reprezentanci obu standard贸w. Pozwala to na wsp贸lne planowanie ich roadmapy, znajdowanie element贸w wsp贸lnych, a tak偶e dbanie o klarowno艣膰 wizji obu projekt贸w i odpowiednie zrozumienie w艣r贸d programist贸w (w tym PR - nad PR Enterprise Edition musi popracowa膰 jak ma艂o kto).

W zesz艂ym tygodniu CN4J postanowi艂o przedstawi膰 sw贸j punkt widzenia na dalszy rozw贸j obu projekt贸w. Jakarta EE ma by膰 przeznaczona do aplikacji monolitycznych oraz mikroserwisowych, ale z du偶ym naciskiem na utrzymanie wstecznej kompatybilno艣ci - to wszystko przy pojedynczym, du偶ym rocznym wydaniu. MicroProfile podbiera sobie z Jakarty EE to co mu pasuje, ma mie膰 mniejszy nacisk na wsteczn膮 kompatybilno艣膰, skupia膰 si臋 na nowych perspektywach rozwoju i i艣cie za trendami rynkowymi (GraphQL, OpenTelemetry). Dzi臋ki oddzielenie Mikroprofilu z Jakarty EE, mo偶liwe jest wydawanie kilku nowych wersji w ci膮gu jednego roku.

Czy spo艂eczno艣膰 kupuje ten podzia艂? 艢rednio. Jak wida膰 na za艂膮czonej ankiecie, grubo ponad po艂owa spo艂eczno艣ci jest za w艂膮czeniem Microprofilu do Jakarty EE i to w spos贸b najbardziej radykalny - zmieniaj膮c jego przestrze艅 nazw, licz膮c si臋 z podobn膮 klas膮 problem贸w, kt贸re nie przesta艂y jeszcze realnie dotyka膰 Jakarty. Ja osobi艣cie by艂bym za opcj膮 A1, aczkolwiek pewnie wynika to z tego powodu, 偶e troch臋 m臋czy mnie ju偶 odyseja z wychodzeniem z Javowego namespace. Mo偶e po prostu moje my艣lenie nie wybiega tak d艂ugoterminowo jak wi臋kszo艣ci g艂osuj膮cych, a mo偶e przebija si臋 przez to m贸j pragmatyzm.

B臋dziemy 艣ledzi膰 dalsze ruchy CN4J i informowa膰 Was o ciekawych og艂oszeniach.

殴r贸d艂a:

3. Ka艂szkwa艂 w sprawie SecruityManagera 馃挬 / tw贸rcy JDK chc膮 przepisa膰 mechanizm Refleksji 馃椌

A na koniec, pierwszy raz w historii JVMowych Wtork贸w robimy followupa do tematu z poprzedniego tygodnia.

Pami臋tacie jak przy okazji poprzedniego tygodnia wspomnieli艣my o niepozornym JEPie, zwi膮zanym z usuni臋ciem Security Managera i tym, 偶e NetBeansom si臋 to bardzo nie podoba艂o? Okazuje si臋, 偶e nie tylko NetBeansom. 聽

Lista mailingowa JDK wr臋cz zalana zosta艂a krytyk膮 JEP 411. Tw贸rcom Javy zarzucane jest lenistwo, brak wypracowania sensownych alternatyw (innych ni偶 "przykro nam, napisz sobie Agenta do maszyny wirtualnej") - szczeg贸lnie aktywnym dyskutantem jest Reinier Zwitserloot, jeden z tw贸rc贸w Lomboka. Z drugiej strony w rozmowie bierze udzia艂 min. przywo艂any w poprzedniej edycji Ron Pressler czy Alex Bateman, kt贸rzy odbijaj膮 pi艂eczk臋. Zarzucaj膮 oni krytykom, 偶e o ile tak naprawd臋 wiele ich argumentum-at-securitum jest do艣膰 trafnych, to w realnym 艣wiecie nikt nie zwraca na przywo艂ywane aspekty uwagi - typu sandboxowanie u偶ycia bibliotek zewn臋trznych. Przyznam, 偶e dyskusja jest naprawd臋 ciekawa i pozwoli艂a mi dowiedzie膰 si臋 naprawd臋 du偶o na temat niuans贸w u偶ycia SecurityManagera.

Za zwr贸cenie uwagi na ten pi臋kny ka艂szkwa艂 na li艣cie mailingowej Javy chcia艂em podzi臋kowa膰 Micha艂owi Rowickiemu. Podrzuci艂 te偶 bardzo fajny materia艂, kt贸ry mnie osobi艣cie pozwoli艂 sporo nauczy膰 si臋 o samym Security Managerze.鈥屸

A 偶e JVM Tuesday bawi i uczy z JEP贸w, podrzucamy kolejnego 艣wie偶o opublikowanego, tym razem jeszcze w formie draftu - JEP draft: Reimplement Core Reflection on Method Handles. Przynosi on ze sob膮 propozycje bardzo grubych zmian w mechanizmie refleksji Javy. 聽Ponownie jest to motywowane pr贸b膮 zmniejszenia z艂o偶ono艣ci implementacji i 艂atwo艣ci膮 zmian.

Okazuje si臋 bowiem, 偶e w kodzie JDK istniej膮 trzy mechanizmy refleksji - natywny java.lang.reflect (w wersji 鈥渟tandardowej鈥 przy u偶yciu tak zwanych natywnych ramek, oraz dodatkowo generowanego pomocniczego bajtkodu w procesie podobnym do tego jak dzia艂a JIT - po odpowiedniej ilo艣ci u偶y膰) oraz java.lang.invoke, s艂awny invoke dynamics wprowadzony wraz z Jav膮 7. Sprawia to, 偶e ka偶dy nowy feature (w JEPie przywo艂any jest Projekt Valhalla, ale jest to niefortunne r贸wnie偶 dla Looma) musi uwzgl臋dnia膰 zmiany we wszystkich tych miejscach.

O ile rozwi膮zanie oparte na natywnych ramkach pozostanie, to ju偶 dodatkowy mechanizm generowania bajtkodu w czasach gdy istnieje wywo艂ywanie dynamiczne jest czym艣 mocno nadmiarowym. Dlatego te偶 rozwi膮zaniem, kt贸re zosta艂o zaproponowane, to przepisanie wewn臋trznej implementacji java.lang.reflect na java.lang.invoke, bez zmian w samym API. Dzi臋ki temu zmniejsz膮 si臋 koszty utrzymania ca艂o艣ci, a 偶e java.lang.invoke jest te偶 API nowocze艣niejszym i wydajniejszym (a tak偶e nie u偶ywaj膮cym Unsafe API), potencjalnie b臋dzie mo偶na uzyska膰 r贸wnie偶 szybsz膮 implementacje - aczkolwiek w tym aspekcie tw贸rcy JEPa chc膮 sytuacji po prostu nie pogorszy膰, ich g艂贸wnym celem jest jednak narzut zwi膮zany z utrzymaniem. Ca艂o艣膰 przypomina zmiany z JDK 13, gdzie w podobny spos贸b potraktowano Socket API - przepisano je 鈥減od spodem鈥 na java.nio

Ah, ale si臋 Ci architekci JDK zabrali za sp艂acanie d艂ugu technicznego.

A za tydzie艅, je艣li nie stanie si臋 nic na tyle du偶ego, 偶e zag艂odzi nam edycje, opowiemy o innym ciekawym proposalu - Local Scopes.

殴r贸d艂a