<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ties van de Ven on JAVAPRO International</title><link>https://javapro-en.svenruppert.com/authors/ties-van-de-ven/</link><description>Recent content in Ties van de Ven on JAVAPRO International</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Wed, 24 Sep 2025 07:00:03 +0000</lastBuildDate><atom:link href="https://javapro-en.svenruppert.com/authors/ties-van-de-ven/index.xml" rel="self" type="application/rss+xml"/><item><title>State management explained</title><link>https://javapro-en.svenruppert.com/state-management-explained/</link><pubDate>Wed, 24 Sep 2025 07:00:03 +0000</pubDate><guid>https://javapro-en.svenruppert.com/state-management-explained/</guid><description>&lt;p&gt;State causes a lot of complexity, is the main source of (weird) bugs and introduces high cognitive load to software engineers so it is important to handle it with care. In this article we go into the problems of (mutable) state, how and when to use mutable and immutable state, and how we can use our type system to prevent us from making mistakes.&lt;/p&gt;
&lt;h2 id="why-state-management-matters"&gt;Why State Management Matters&lt;/h2&gt;
&lt;p&gt;Most bugs out there are in one way related to state. Some examples are things like race conditions, null pointer exceptions and inconsistent behavior. And let&amp;rsquo;s not forget the famous quote &amp;ldquo;Have you tried turning it off and on again&amp;rdquo; that seems to fix most problems. This tends to work because resetting the device or software causes it to start with a new fresh state. Mutable state can also cause headaches when doing concurrent programming, but because most developers do not write multi-threaded software on a day to day basis, let&amp;rsquo;s focus for now on problems that are always present: complexity and high cognitive load.&lt;/p&gt;</description></item></channel></rss>