<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sealed-Classes on Devops Monk</title><link>https://devops-monk.com/tags/sealed-classes/</link><description>Recent content in Sealed-Classes on Devops Monk</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 04 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://devops-monk.com/tags/sealed-classes/index.xml" rel="self" type="application/rss+xml"/><item><title>Sealed Classes (JEP 409): Controlled, Exhaustive Class Hierarchies</title><link>https://devops-monk.com/tutorials/java17/sealed-classes/</link><pubDate>Mon, 04 May 2026 00:00:00 +0000</pubDate><guid>https://devops-monk.com/tutorials/java17/sealed-classes/</guid><description>Finalized in Java 17 (JEP 409). This is the headline language feature of the Java 17 LTS release. Previous previews: Java 15 (JEP 360) and Java 16 (JEP 397).
The Problem: Open Hierarchies Are Hard to Reason About In Java, any class can be extended by default. This openness is flexible but has costs.
Consider a Shape interface used in a drawing application:
// Java 11 — anyone can implement Shape public interface Shape { double area(); } At runtime, a Shape instance could be a Circle, a Rectangle, a Triangle, or anything else in the classpath.</description></item></channel></rss>