<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Richard Gross on JAVAPRO International</title><link>https://javapro-en.svenruppert.com/authors/richard-gross/</link><description>Recent content in Richard Gross on JAVAPRO International</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 26 May 2026 07:00:00 +0000</lastBuildDate><atom:link href="https://javapro-en.svenruppert.com/authors/richard-gross/index.xml" rel="self" type="application/rss+xml"/><item><title>Destructoring is the future of Javas Encapsulation</title><link>https://javapro-en.svenruppert.com/destructoring-is-the-future-of-javas-encapsulation/</link><pubDate>Tue, 26 May 2026 07:00:00 +0000</pubDate><guid>https://javapro-en.svenruppert.com/destructoring-is-the-future-of-javas-encapsulation/</guid><description>&lt;p&gt;Encapsulation in Java has been broken &lt;a href="https://openjdk.org/jeps/500#Serialization-libraries-should-use-sun-reflect-ReflectionFactory"&gt;since the Java Development Kit (JDK) 5&lt;/a&gt;. Objects &lt;em&gt;should&lt;/em&gt; guarantee that their inner state matches what we cast into code, but at runtime any &lt;code&gt;private&lt;/code&gt; and &lt;code&gt;final&lt;/code&gt; state can be set from the outside to any value — bypassing any checks and asserts. This is possible through the Reflection Api, which allows to &lt;code&gt;setAccessible&lt;/code&gt; any &lt;code&gt;private&lt;/code&gt; field and then &lt;code&gt;set&lt;/code&gt; the value of any &lt;code&gt;final&lt;/code&gt; field. This specific use of the Reflection Api to mutate an immutable &lt;code&gt;final&lt;/code&gt; field is called &lt;em&gt;deep reflection&lt;/em&gt;.&lt;/p&gt;</description></item><item><title>Kotlin kontra Java - Part 3 - Language for Interop</title><link>https://javapro-en.svenruppert.com/kotlin-kontra-java-part-3-language-for-interop/</link><pubDate>Thu, 07 May 2026 07:00:01 +0000</pubDate><guid>https://javapro-en.svenruppert.com/kotlin-kontra-java-part-3-language-for-interop/</guid><description>&lt;p&gt;When you start a new project on the JVM, should you pick Java or Kotlin? Why not both?&lt;/p&gt;
&lt;p&gt;You can use any Java library you want in Kotlin, you can even co-write your software in both languages (e.g. one team I work with writes their JUnit tests in Kotlin, their main code in Java) and migrate to Kotlin or back to Java over time. &lt;a href="https://kotlinlang.org/docs/java-interop.html"&gt;Kotlin is designed with Java interoperability in mind&lt;/a&gt;, because JetBrains wanted to migrate their IDEs (IntelliJ IDEA, WebStorm, etc.) incrementally to the language. But how does that work? What does Kotlin do, so that interop to this degree becomes possible?&lt;/p&gt;</description></item><item><title>Kotlin kontra Java - Part 2 - MultiPlatform</title><link>https://javapro-en.svenruppert.com/kotlin-kontra-java-part-2-multiplatform/</link><pubDate>Wed, 22 Apr 2026 07:45:01 +0000</pubDate><guid>https://javapro-en.svenruppert.com/kotlin-kontra-java-part-2-multiplatform/</guid><description>&lt;p&gt;When you start a new project on the JVM, should you pick Java or Kotlin?&lt;/p&gt;
&lt;p&gt;You might have a preference based on the ecosystem — the tooling around it, who we can ask for help, and the libraries we can use — which we discussed in &lt;a href="https://javapro.io/2026/04/16/kotlin-kontra-java-part-1-ecosystem/"&gt;part 1&lt;/a&gt; of this article series. Or you might have a preference based on the business modeling capabilities of Java or Kotlin, which we will show in &lt;a href="https://javapro.io/2026/05/07/kotlin-kontra-java-part-3-language-for-interop/"&gt;part 3&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Kotlin kontra Java - Part 1 - Ecosystem</title><link>https://javapro-en.svenruppert.com/kotlin-kontra-java-part-1-ecosystem/</link><pubDate>Thu, 16 Apr 2026 07:00:00 +0000</pubDate><guid>https://javapro-en.svenruppert.com/kotlin-kontra-java-part-1-ecosystem/</guid><description>&lt;p&gt;When you start a new project on the JVM, should you pick Java or Kotlin?&lt;/p&gt;
&lt;p&gt;Kotlin is used by Amazon, Atlassian, Duolingo, Google, JetBrains, Meta, Netflix, Uber and many more. Java is used by, well, &lt;a href="https://blogs.oracle.com/connect/25-years-java-technology-community-family"&gt;„more than 3 billion devices“&lt;/a&gt;. Which one provides the biggest benefit, which one can give us an edge, which one should we pick?&lt;/p&gt;
&lt;p&gt;After 20 years of building systems in Java and 8 years of doing the same in Kotlin, I’ve seen Kotlin earn its reputation as a natural evolution of Java. Rightfully so. Much of what we need can be expressed very cleanly with little verbosity.&lt;/p&gt;</description></item><item><title>Map your Code - Master your Architecture</title><link>https://javapro-en.svenruppert.com/map-your-code-master-your-architecture/</link><pubDate>Tue, 21 Oct 2025 07:00:01 +0000</pubDate><guid>https://javapro-en.svenruppert.com/map-your-code-master-your-architecture/</guid><description>&lt;p&gt;In projects with hundreds of thousands of lines, it is easy to lose track of code, architecture and quality. Are we still on the right track, are we blocking ourselves with internal dependencies, or are we already stuck? Software is immaterial; we cannot see how it is doing.&lt;/p&gt;
&lt;p&gt;To know how our software is doing, we have systematically check if the mental models of the developers matches the written code. Spoiler, they do not, as software changes too fast to keep track, every developer has their own model and no one has the complete picture.&lt;/p&gt;</description></item><item><title>Fixing the Billion-Dollar Mistake</title><link>https://javapro-en.svenruppert.com/fixing-the-billion-dollar-mistake/</link><pubDate>Thu, 07 Aug 2025 07:00:00 +0000</pubDate><guid>https://javapro-en.svenruppert.com/fixing-the-billion-dollar-mistake/</guid><description>&lt;p&gt;&lt;em&gt;There are mistakes that are just costly. Then there is the null reference. A language feature that was added in 1965 &amp;ldquo;simply because it was so easy to implement&amp;rdquo;. Since then, null references have caused countless bugs, system crashes and security problems - and cost billions of dollars in maintenance and troubleshooting. It has been eliminated in many new programming languages and this article will show the practical ways to eliminate this language mistake even in Java.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>A visual chronicle of the JDK's journey</title><link>https://javapro-en.svenruppert.com/a-visual-chronicle-of-the-jdks-journey/</link><pubDate>Tue, 08 Jul 2025 07:00:01 +0000</pubDate><guid>https://javapro-en.svenruppert.com/a-visual-chronicle-of-the-jdks-journey/</guid><description>&lt;p&gt;The Java Development Kit (JDK) has undergone significant transformations since its inception. From it&amp;rsquo;s &amp;ldquo;write-once, run everywhere&amp;rdquo; beginnings, over the applet wars, through the first release of the OpenJDK to the new release cadence, that has kept us occupied for the last eight years already. In 30 years a lot has happened.&lt;/p&gt;
&lt;p&gt;Most of that journey is chronicled only in, arguably, dry textual representation. The text tells us how many features were added, changed or, very seldomly, removed. It does not tell us what impact that had on the code. What were the key architectural changes, what were the refinements and how were the complexities of such a large code base handled?&lt;/p&gt;</description></item></channel></rss>