Wysypało nam releaseami – tydzień temu Kotlin 1.5, dzisiaj Scala 3 🥳. Oprócz tego nieco wyjaśnień z frontu Jakarty EE oraz dalszy ciąg naszego cotygodniowego przeglądu nowych JEPów.
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ą
Ź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. 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:
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. 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 “standardowej” 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 “pod spodem” na java.nio
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
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
