Java developers often struggle with fatjar deployments, where adding or updating modules requires rebuilding and restarting the entire application. The Solon framework community has proposed two complementary plugin extension strategies to address this. E-Spi (External SPI) allows extensions to be added via external configuration and plugin JARs, keeping the core application lean. It is simple and reliable, but requires a restart to take effect, making it suitable for configuration externalization and module splitting scenarios. H-Spi (Hot SPI), on the other hand, uses an independent ClassLoader to load and unload modules at runtime, enabling true hot-plugging without downtime. This approach is powerful for dynamic feature toggling and multi-tenant environments, but it demands strict resource lifecycle management to avoid memory leaks and classloader conflicts. The choice between the two depends on whether your priority is operational simplicity or runtime flexibility. This architectural pattern is not limited to Solon—it can inspire similar designs in other Java frameworks, especially for teams building plugin-driven platforms or microservices that need modular evolution.
Explore E-Spi and H-Spi, two plugin extension mechanisms for Java applications that address fatjar deployment pain points, with trade-offs between restart-based simplicity and hot-swap flexibility.