{"id":15868,"date":"2023-05-05T10:11:04","date_gmt":"2023-05-05T08:11:04","guid":{"rendered":"https:\/\/vived.io\/?p=15868"},"modified":"2023-05-05T12:03:06","modified_gmt":"2023-05-05T10:03:06","slug":"rzut-oka-pod-maske-javy-dynamiczni-agenci-i-tearing-jvm-weekly-vol-134","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/rzut-oka-pod-maske-javy-dynamiczni-agenci-i-tearing-jvm-weekly-vol-134\/","title":{"rendered":"Rzut oka pod mask\u0119 Javy: Dynamiczni Agenci i „tearing” – JVM Weekly vol. 134"},"content":{"rendered":"\n

1. Quarkus dostaje wydanie 3.0<\/h2>\n\n\n\n

Uwielbiam Quarkusa i ca\u0142\u0105 stoj\u0105c\u0105 za nim filozofi\u0119 opart\u0105 o stworzenie nie tylko samego (wydajnego) frameworki, ale r\u00f3wnie\u017c zestawu narz\u0119dzi, kt\u00f3ry pozwoli na jego efektywne u\u017cycie. W \u015bwiecie, gdzie Spring Boot ma (zas\u0142u\u017cenie, AD 2023 to te\u017c \u015bwietny framework jest) dominuj\u0105c\u0105 pozycj\u0119, mi\u0142o widzie\u0107 realn\u0105 konkurencje, kt\u00f3ra wybra\u0142a sobie swoj\u0105 nisz\u0119 i si\u0119 w niej rozpycha (aplikacje strikte Cloud Native, \u0142\u0105cznie z funkcjami serverless, w kt\u00f3rych wsparciu akurat bije javowego Goliata). Jako, \u017ce historycznie mia\u0142em te\u017c sporo do\u015bwiadczenia z platform\u0105 Java EE, w dalszym ci\u0105gu ci\u0119\u017cko mi uwierzy\u0107, jak wiele pracy wykonano, by pozby\u0107 si\u0119 z\u0142ej s\u0142awy standardu, a RedHat z pewno\u015bci\u0105 do\u0142o\u017cy\u0142 do tego cegie\u0142k\u0119. Dlatego te\u017c na Quarkus 3.0<\/a> czeka\u0142em z niecierpliwo\u015bci\u0105, poniewa\u017c poza standardowymi zmianami, zgodnymi z kierunkiem w kt\u00f3rym idzie ca\u0142y ekosystem (Jakarta EE 10, MicroProfile 6.0, Hibernate 6.0 i Reactive czy zapowied\u017a porzucenia wsparcia dla JDK 11) dok\u0142ada on kilka swoich w\u0142asnych, unikalnych smaczk\u00f3w.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

Zacznijmy od Dev UI, kt\u00f3re z jednej strony pokazuje pewne korzenie Quarkusa – tego typu cude\u0144ka to raczej zawsze by\u0142y domen\u0105 serwer\u00f3w aplikacyjnych, z drugiej za\u015b uzmys\u0142awia, jak wiele dobrych pomys\u0142\u00f3w istnia\u0142o w takich wydawa\u0142oby si\u0119 antycznych ju\u017c rozwi\u0105zaniach – do\u015b\u0107 wymieni\u0107 panel do zmienianie opcji konfiguracyjnych czy zarz\u0105dzaniu rozszerzeniami. I oczywi\u015bcie, Dev UI pojawi\u0142o si\u0119 ju\u017c przy okazji Quarkusa 2.0, ale teraz zosta\u0142o znacznie rozbudowane i wygodniejsze w obs\u0142udze. Maj\u0105cy do\u015bwiadczenie z rozwi\u0105zaniami frontendowymi szybko rozpoznaj\u0105 te\u017c drugiego rodzica tego rozwi\u0105zania – dzi\u0119ki temu, \u017ce Quarkus mo\u017cna uruchomi\u0107 w tak zwanym Dev Mode, dost\u0119pne s\u0105 takie featury jak Continouse Testing (uwierzcie mi, it makes a difference). I oczywi\u015bcie nie jest tak, \u017ce Quarkus jako jedyny posiada takie mo\u017cliwo\u015bci, ale jest to jedyny z popularnych framework\u00f3w, kt\u00f3ry traktuje je jako obywateli pierwszej kategorii, a nie jako dodatek – i to czu\u0107.<\/p>\n\n\n\n

Niezwykle interesuj\u0105c\u0105 zmian\u0105 jest te\u017c wprowadzenie Mutiny2. Mutiny to biblioteka Java opracowana przez zesp\u00f3\u0142 Quarkus w celu uproszczenia implementacji programowania reaktywnego i asynchronicznego. Jak to bywa w wypadku projekt\u00f3w Quarkusa, zosta\u0142a zaprojektowana tak, aby by\u0142 intuicyjne i proste podej\u015bcie do pisania kodu reaktywnego w por\u00f3wnaniu do innych bibliotek, takich jak RxJava i Project Reactor. Mutiny podobnie jak wymienione przed chwil\u0105 projekty jest implementacj\u0105 Reactive Streams. Dla tych kt\u00f3rzy mog\u0105 nie kojarzy\u0107, Reactive Streams API jest standardem dla asynchronicznego, nieblokuj\u0105cego i \u015bwiadomego backpressure przetwarzania strumieni danych w Javie, promuj\u0105c interoperacyjno\u015b\u0107 w\u015br\u00f3d bibliotek i framework\u00f3w programowania reaktywnego. W okolicach JDK 9 by\u0142 to jeden z najg\u0142o\u015bniejszych temat\u00f3w w ca\u0142ym JDK, ale jako \u017ce hype na programowanie reaktywne nieco ju\u017c min\u0105\u0142, przesta\u0142y si\u0119 te\u017c jak grzyby po deszczu pojawia\u0107 kolejne implementacji. Dlatego te\u017c Mutiny postanowi\u0142o odpu\u015bci\u0107 sobie „do abstrakcji” Reactive Streams<\/a>, a zamiast tego u\u017cy\u0107 po prostu referencyjnej wersji z JDK – java.util.concurrent.Flow<\/code>. Jest to chyba pewne symboliczne domkni\u0119cie pewnej epoki.<\/p>\n\n\n\n

Czego mi jednak zabrak\u0142o? Mia\u0142em nadzieje, \u017ce dostaniemy jakie\u015b szersze wsparcie wirtualnych w\u0105tk\u00f3w, kt\u00f3re by\u0142o wspomniane w momencie og\u0142oszenia prac nad wersj\u0105 3.0. Zrobi\u0142em sobie ma\u0142e review kodu i na ten moment w dalszym ci\u0105gu najciekawszym fragmentem wsparcia VirtualThreads w pozostaje rozszerzenie do resteasy-reactive<\/code>, kt\u00f3re zreszt\u0105 nie wyewoluowa\u0142o jako\u015b mocno od czasu oryginalnej publikacji rok temu przy okazji JDK 19. Obrazuje ono zreszt\u0105 bardzo dobrze, jak bardzo defensywnym jest dzisiaj programowanie wsparcia dla sztandarowego dziecka Looma: Zobaczcie zreszt\u0105 sami lekko uproszczony przyk\u0142ad, oryginaln\u0105 klas\u0119 znajdziecie tutaj<\/a>:<\/p>\n\n\n\n

private boolean isRunOnVirtualThread(MethodInfo info, BlockingDefault defaultValue) {\n    boolean isRunOnVirtualThread = false;\n    (...)\n    Map.Entry<AnnotationTarget, AnnotationInstance> transactional = getInheritableAnnotation(info, TRANSACTIONAL); \n    \n    if (transactional != null) {\n            return false;\n        }\n        \n    if (runOnVirtualThreadAnnotation != null) {\n        if (!JDK_SUPPORTS_VIRTUAL_THREADS) \n        {\n          throw new DeploymentException((...))\n        }\n          \n      if (targetJavaVersion.isJava19OrHigher() == Status.FALSE) {\n         throw new DeploymentException((...))\n        }\n            isRunOnVirtualThread = true;\n   }\n\n   if (defaultValue == BlockingDefault.BLOCKING) {\n        return false;\n   } else if (defaultValue == BlockingDefault.RUN_ON_VIRTUAL_THREAD) {\n            isRunOnVirtualThread = true;\n    } else if (defaultValue == BlockingDefault.NON_BLOCKING) {\n            return false;\n    }\n\n    if (isRunOnVirtualThread && !isBlocking(info, defaultValue)) {\n         throw new DeploymentException((...))\n    } else if (isRunOnVirtualThread) {\n         return true;\n    }\n\n    return false\n}\n<\/code><\/pre>\n\n\n\n
Tak\u017ce je\u017celi kiedykolwiek czuli\u015bcie si\u0119 \u017ale, u\u017cywaj\u0105c masy zagnie\u017cd\u017conych if-\u00f3w, to mam nadzieje, \u017ce widz\u0105 powy\u017csze jest Wam ju\u017c troch\u0119 lepiej.<\/p>\n\n\n\n
\u0179r\u00f3d\u0142a<\/h3>\n\n\n\n