Kiedy Programista Java spotyka C / Serial(izacja) i niekończąca się opowieść…

Cześć!

Wspólnie z łódzkim oddziałem Sii mamy ogromną przyjemność zaprosić Was na kolejne spotkanie JUG Łódź - tym razem odwiedzają nas Jarek Pałka i Michał Jonko z Neo4j.

Kiedy Programista Java spotyka C
Java od lat żyje z łatką języka, który absolutnie nie nadaje się do pisania bardzo wydajnych systemów. Jako programista nie masz kontroli nad tym, kiedy GC, JIT czy JNI postanowią zniszczyć Twoje sny o niskim latency. A mimo to ktoś wciąż próbuje budować na tym bazy danych i systemy "bliżej metalu". W tej prezentacji pokażę, że wraz z Java 22 dostaliśmy potężne narzędzie: Foreign Memory & Foreign Function API. Dzięki tym API praca z off-heap staje się bezpieczna (oczywiście w pewnych granicach — ale to Ty je określasz), co pozwala pozbyć się pauz GC. A Foreign Functions umożliwiają bezpieczne wywoływanie kodu w C z poziomu Javy, bez potrzeby używania javah, kompilatorów C i całęgo zestawu zaklęć potrzebnych, by JNI łaskawie zadziałało.
Zobaczycie, jak te nowe API przybliżają JVM do świata bare-metal — i dlaczego mogą stać się przyszłością systemów data-intensive, baz danych, a nawet narzędzi ML/AI. A wszystko oczywiście doprawione niedziałającymi przykładami i benchmarkami przygotowanymi pięć minut przed prezentacją.

Java od lat żyje z łatką języka, który absolutnie nie nadaje się do pisania bardzo wydajnych systemów. Jako programista nie masz kontroli nad tym, kiedy GC, JIT czy JNI postanowią zniszczyć Twoje sny o niskim latency. A mimo to ktoś wciąż próbuje budować na tym bazy danych i systemy "bliżej metalu". W tej prezentacji pokażę, że wraz z Java 22 dostaliśmy potężne narzędzie: Foreign Memory & Foreign Function API. Dzięki tym API praca z off-heap staje się bezpieczna (oczywiście w pewnych granicach — ale to Ty je określasz), co pozwala pozbyć się pauz GC. A Foreign Functions umożliwiają bezpieczne wywoływanie kodu w C z poziomu Javy, bez potrzeby używania javah, kompilatorów C i całęgo zestawu zaklęć potrzebnych, by JNI łaskawie zadziałało.
Zobaczycie, jak te nowe API przybliżają JVM do świata bare-metal — i dlaczego mogą stać się przyszłością systemów data-intensive, baz danych, a nawet narzędzi ML/AI. A wszystko oczywiście doprawione niedziałającymi przykładami i benchmarkami przygotowanymi pięć minut przed prezentacją.

Jarek Pałka
Od ponad 20 lat w branży IT jako administrator baz danych, programista, architekt, manager i „inżynier od spraw katastrof”. Brałem udział w małych, średnich i nonsensownie dużych projektach, prowadzonych zgodnie zasadami „waterfall”, Agile oraz przy braku jakichkolwiek metodyk – z tym samym zawsze skutkiem. Wszystko to doprowadziło mnie do wniosku, że nieważne co robisz, ważne byś robił to dobrze, w najprostszy z możliwych sposobów i przy użyciu właściwych narzędzi, które wykonają pracę za Ciebie. W międzyczasie dałem się porwać ideom TDD oraz Software Craftmanship, do granic możliwości wyeksploatować tak piękne w swej prostocie pomysły jak REST i NoSQL. Porzuciłem je, by zgłębić tajniki „system thinking” i zachwycić się siłą, jaką niesie ze sobą „metafora” oraz by odkryć, że rządzą nami te same prawa „natury”. Niepokorny wyznawca kościoła JVM, badacz bytecode’u i JIT oraz wszelkiej maści parserów, interpreterów i kompilatorów. Na co dzień walczący o lepszą wydajność w Neo4j. Od czasu do czasu można usłyszeć moje niskiej jakości żarty na temat architektury na konferencjach w Polsce.
W wolnych chwilach trener w Symentis, autor bloga na http://geekyprimitives.wordpress.com/ oraz samozwańczy dyktator w radach programowych wielu konferencji.

Serial(izacja) i niekończąca się opowieść…
Od niepamiętnych czasów, od kiedy SOAP, REST i “wiecznie żywy” Spring stały się standardem w branży, serializacja z wykorzystaniem XML czy uwielbianego przez frontendowców JSON, stała się “normalnością”. Większość z nas nie zastanawia się jednak, czy w dzisiejszym świecie, pełnym optymalizacji śladu węglowego i zwiększającym się kosztom usług, istnieje “lepsze” rozwiązanie problemu serializacji i wymiany danych, szczególnie na poziomie wieloplatformowym - nie tylko Java, JavaScript, czy .NET.
Inspiracją dla tej prezentacji stały się prawdziwe wydarzenia, gdzie pewnej nocy podczas burzliwie wykonujących się testów wydajnościowych, JVM zabrał się za konwersję danych pomiędzy różnymi formatami, a następnie z uśmiechem w logach wywołał OutOfMemoryError. Postaram się pokazać metody i biblioteki (wspomnę o Kryo, Apache Fory, Protobuf, …) służące serializacji, których użycie warto rozważyć w przyszłych projektach.

Michał Jonko
Od prawie 20 lat w branży, gdzie spełnia się jako inżynier oprogramowania (chyba) każdego szczebla, a praca z JVM jest miłością pełną idealizacji i huśtawki emocjonalnej.
Pasjonat optymalizacji, walki z wydajnością, automatyzacji, identyfikacji procesów i systemów decyzyjnych. Niestety również wymagający maruda, wielki “wielbiciel” Agile (pełnił nawet funkcję Agile Advocate), czciciel czytelnego i łatwego w utrzymaniu kodu funkcyjnego.
Obecnie inżynier w Neo4j, szukający “szybkości” i “niskich kosztów”, gdzie zdarzyć się może wszystko (a najczęściej zdarza się to, czego się nie spodziewało).