<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Dmitry Moskalyuk on foojay.io - Friends Of OpenJDK</title><link>http://foojayio.github.io/website/today/author/dmitry-moskalyuk/</link><description>Articles written by Dmitry Moskalyuk on foojay.io - Friends Of OpenJDK</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 10 Sep 2026 06:56:00 +0000</lastBuildDate><atom:link href="http://foojayio.github.io/website/today/author/dmitry-moskalyuk/index.xml" rel="self" type="application/rss+xml"/><item><title>Reflection-Free Serialization on the JVM: Four Formats In, Avro Out</title><link>http://foojayio.github.io/website/today/reflection-free-serialization-on-the-jvm-four-formats-in-avro-out/</link><pubDate>Thu, 10 Sep 2026 06:56:00 +0000</pubDate><guid>http://foojayio.github.io/website/today/reflection-free-serialization-on-the-jvm-four-formats-in-avro-out/</guid><description>&lt;p&gt;I run a model layer that accepts the same business data in JSON, XML, YAML, and TOML and converts it all to Avro. The project was greenfield, so the question was never what to migrate away from. It was a question of which serialization library the layer would be built with: Jackson or kotlinx.serialization. Jackson was the safe answer, with a module for every format we needed and years of production behind it. What pulled me the other way was the assumption that runtime reflection costs real CPU under load. That turned out to be true of one Jackson path and not the other, which I will get to. The reasons the choice held up were not the reasons I made it.&lt;/p&gt;</description></item></channel></rss>