<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Modules on Devops Monk</title><link>https://devops-monk.com/tags/modules/</link><description>Recent content in Modules 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/modules/index.xml" rel="self" type="application/rss+xml"/><item><title>Module System (JPMS, JEP 261): Project Jigsaw Deep Dive</title><link>https://devops-monk.com/tutorials/java11/module-system/</link><pubDate>Mon, 04 May 2026 00:00:00 +0000</pubDate><guid>https://devops-monk.com/tutorials/java11/module-system/</guid><description>The Problem JPMS Solves Before Java 9, the JDK had no real notion of encapsulation at the library level. public meant accessible to everyone — including internal JDK classes like sun.misc.Unsafe and com.sun.internal.*. Large codebases suffered from:
No reliable encapsulation: Any public class in any JAR was reachable from any other JAR. Classpath hell: Duplicate or conflicting classes from different JARs led to unpredictable behaviour. Monolithic JDK: The entire 60+ module JDK had to ship with every application.</description></item></channel></rss>