{"id":16963,"date":"2023-11-08T09:55:43","date_gmt":"2023-11-08T08:55:43","guid":{"rendered":"https:\/\/vived.io\/?p=16963"},"modified":"2023-11-09T12:57:59","modified_gmt":"2023-11-09T11:57:59","slug":"play-framework-odradza-sie-jak-feniks-z-popiolow-i-pozbywa-akki-jvm-weekly-vol-153","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/play-framework-odradza-sie-jak-feniks-z-popiolow-i-pozbywa-akki-jvm-weekly-vol-153\/","title":{"rendered":"Play Framework odradza si\u0119 jak feniks z popio\u0142\u00f3w… i pozbywa Akki – JVM Weekly vol. 153"},"content":{"rendered":"\n

1. Bo dawno nie by\u0142o JEP-\u00f3w… no to nowe JEPy!<\/h2>\n\n\n\n

JEP draft: Ahead of Time Compilation for the Java Virtual Machine<\/a><\/h3>\n\n\n\n

No i mamy pierwsze odpryski projektu Leyden, pomimo, \u017ce sam JEP nie jest do niego na razie przypi\u0119ty – cho\u0107 mo\u017ce to po prostu jeszcze kwestia pozostawania w Drafcie. Mimo wszystko, jest na tyle interesuj\u0105cy, \u017ce postanawiam o nim wspomnie\u0107 ju\u017c na tak wczesnym etapie.<\/p>\n\n\n\n

JEP draft: Ahead of Time Compilation for the Java Virtual Machine<\/a> rozwija\u0107 ma JVM o mo\u017cliwo\u015b\u0107 wczytywania aplikacji i bibliotek, kt\u00f3re zosta\u0142y skompilowane do natywnego kodu Ahead of Time. Cel jest jak zawsze ostatnio – przyspieszenie start aplikacji i startow\u0105 wydajno\u015b\u0107 wykonania. Tw\u00f3rcy chc\u0105 przeciwdzia\u0142a\u0107 problemom z wydajno\u015bci\u0105, wynikaj\u0105cym z obecnego dynamicznego modelu wykonania w trzech etapach: wst\u0119pnego interpretowania (Tier 0), kompilacji C1 (Tier 3), a nast\u0119pnie C2 (Tier 4), gdzie etapy 1 i 2 dotycz\u0105 specjalnych przypadk\u00f3w kompilacji C1. Ca\u0142\u0105 operacje mo\u017cna by robi\u0107 od razu kompilatorem C2, ale realnie powodowa\u0142oby to d\u0142ugi „rozruch” optymalizowanej wersji. Dobrym przyk\u0142adem jest kompilator Graal, kt\u00f3ry przed Java 17 by\u0142 dost\u0119pnym zamiennikiem dla C2, ale jego uruchomienie negatywnie wp\u0142ywa\u0142o na aplikacj\u0119, poniewa\u017c on sam musia\u0142 zosta\u0107 skompilowany przed rozpocz\u0119ciem efektywnej pracy. Ponadto proces deoptymalizacji, kt\u00f3ry ma miejsce, gdy skompilowany przez C2 kod trafia na b\u0142\u0119dne za\u0142o\u017cenie optymalizacyjne, jest kosztowny, poniewa\u017c wariant profiluj\u0105cy C1 musi zosta\u0107 ponownie skompilowany, a nast\u0119pnie odrzucony po ponownej kompilacji przez C2.<\/p>\n\n\n\n

Sam draft jest bardzo WIP (nie posiada nawet pe\u0142nego opisu), ale b\u0119d\u0119 monitorowa\u0142 temat i na pewno do niego wr\u00f3cimy.<\/p>\n\n\n\n

JEP 461: Stream Gatherers (Preview)<\/a><\/h3>\n\n\n\n

Co si\u0119 stanie kiedy by\u0142y Tech Lead Akki, Viktor Klang, zaproponuje zmiany w Stream API? Wygl\u0105da na to, \u017ce dostajemy bardzo przemy\u015blan\u0105 propozycje kierunku, w kt\u00f3rym chyba najlepiej zaadoptowana w ostatniej dekadzie nowo\u015b\u0107 w j\u0119zyku mo\u017ce by\u0107 rozwijana.<\/p>\n\n\n\n

Chocia\u017c istniej\u0105cy interfejs Stream API oferuje ju\u017c bogaty zestaw operacji procesuj\u0105cych (jak .map<\/code>, .filter<\/code> ), istnia\u0142a potrzeba rozszerzenia go i takie jak fixedWindow(2)<\/code> czy scan((sum, next) -> sum + next). Propozycja Viktora wynika z powtarzaj\u0105cych si\u0119 pr\u00f3\u015bb o dodanie takich dodatkowych operacji do Stream API w Javie 8, kt\u00f3rych nie mo\u017cna by\u0142o spe\u0142ni\u0107, poniewa\u017c ich u\u017cycie by\u0142o zbyt w\u0105skie, aby umie\u015bci\u0107 je w podstawowym Stream API. Na ten moment nie istnieje jednak opcja, \u017ceby kto\u015b samodzielnie stworzy\u0142 sobie w\u0142asn\u0105 operacje procesuj\u0105c\u0105, jak to ma miejsce w przypadku interfejsu Stream::collect<\/code>, w zwi\u0105zku z czym czasem okazuje si\u0119, \u017ce osi\u0105gni\u0119cie niekt\u00f3rych efekt\u00f3w jest zaskakuj\u0105co trudne.<\/p>\n\n\n

\n
\"\"
Za ka\u017cdym jednym razem…<\/figcaption><\/figure><\/div>\n\n\n

Nowy interfejs Stream::gather<\/code> s\u0142u\u017cy\u0107 ma do tworzenia w\u0142asnych operacja po\u015brednich, zdolna do obs\u0142ugi wielu ich rodzaju. Viktor przeprowadzi\u0142 bowiem w swoim dokumencie Gathering the streams<\/a> wnikliw\u0105 klasyfikacje r\u00f3\u017cnego rodzaju przypadk\u00f3w u\u017cycia nowego API, opisuj\u0105cych r\u00f3\u017cne rodzaje operacji strumieniowych, takich jak operacje po\u015brednie, operacje przyrostowe, operacje stanowe, bezstanowe\u2026 ca\u0142o\u015b\u0107 naprawd\u0119 dobrze opisuje wspomniany ju\u017c oryginalny dokument. Gatherer, bo tak nazwany zosta\u0142 nowy interfejs, w swojej budowie bardzo przypomina dobrze znanego Collectora, na kt\u00f3rym zreszt\u0105 zosta\u0142 oparty. \u017beby Wam to lepiej zwizualizowa\u0107, przyk\u0142adem gatherera jest np. metoda fold<\/code>.<\/p>\n\n\n\n

Najwa\u017cniejsze metody nowego interfejsu to:<\/p>\n\n\n\n

\/** @param <T> the element type\n *  @param <A> the (mutable) intermediate accumulation type\n *  @param <R> the (probably immutable) final accumulation type\n *\/\ninterface Gatherer<T,A,R> {\n    Supplier<A> initializer();\n    Gatherer.Integrator<A,T,R> integrator();\n    BinaryOperator<A> combiner();\n    Function<A, R> finisher();\n    (...)\n}<\/code><\/pre>\n\n\n\n
Gatherer zosta\u0142 zaprojektowany, aby zapewni\u0107 mo\u017cliwo\u015b\u0107 kompozycji i reu\u017cywalno\u015bci poszczeg\u00f3lnych stworzonych z jego pomoc\u0105 komponent\u00f3w. Jako przyk\u0142ad mo\u017ce pos\u0142u\u017cy\u0107 implementacja znanego map na wsp\u00f3lnej abstrakcji:<\/p>\n\n\n\n
 public static <T, R> Gatherer<T, ?, R> map(Function<? super T, ? extends R> mapper) {\n         return Gatherer.of(\n             (unused, element, downstream) -> \/\/ integrator\n                 downstream.push(mapper.apply(element))\n         );\n     }\n<\/code><\/pre>\n\n\n\n
Je\u015bli jeste\u015bcie zainteresowani, bardzo dobre wprowadzenie wideo jak zwykle trafi\u0142o na kana\u0142 Inside Java.<\/p>\n\n\n\n
\n