Java的模块化经历了漫长的演进，从早期的无模块化、到第三方OSGi规范，再到Java 9官方引入的JPMS（Java Platform Module System），以及当前微服务架构下的新思考。这一历程反映了软件工程对封装性、可维护性和部署独立性的追求。
在Java 9之前，Java平台本身是一个巨大的rt.jar（约60MB），包含所有标准库类。开发者使用类路径（classpath）管理依赖，这种方式存在明显缺陷：没有模块边界，所有公有类都相互可见；可能发生类冲突或版本冲突；无法表示内部API。企业级应用通过包命名约定（如com.mycompany）来避免冲突，但无法强制封装。
OSGi（Open Services Gateway initiative）在2000年代初期出现，成为Java模块化的事实标准。OSGi定义了一个动态模块系统，每个模块（bundle）是一个JAR文件，包含元数据（MANIFEST.MF）声明导出的包、依赖的包和版本范围。OSGi运行在专门的框架（如Eclipse Equinox、Apache Felix）中，支持运行时安装、启动、停止、更新模块。OSGi的优势是强大的模块隔离和动态性，被Eclipse IDE、Adobe Experience Manager等大型应用采用。但OSGi的学习曲线陡峭，类加载器模型复杂，与主流开发工具和库（如Spring Boot）集成不便。
Java 9正式引入了JPMS，旨在提供轻量级的、语言级的模块化。每个模块包含module-info.java文件，声明模块名称、依赖（requires）、导出包（exports）、服务（provides/uses）等。JPMS的模块路径取代了类路径，模块间的可见性由声明决定。JDK本身也被模块化，rt.jar拆分为java.base、java.sql、java.xml等多个模块，开发者可以使用jlink创建只包含必要模块的定制运行时镜像，体积大幅缩减。JPMS还增强了封装性：未导出的包即使在反射下也不可见（除非使用--add-opens）。
然而，JPMS在社区中的采用并不如预期迅速。主要障碍包括：现有库的模块化迁移成本高（需要为每个JAR编写module-info）；双向依赖和循环依赖问题；以及Maven/Gradle等构建工具的支持滞后。许多开源项目（如Spring Framework 6）开始支持模块化，但普通应用开发者仍较少直接使用module-info，而是继续使用类路径，或者仅使用JPMS的部分特性（如jlink）。
与此同时，微服务架构的兴起为模块化提供了另一种视角。微服务将系统拆分为独立的进程，每个服务有自己的部署单元（如容器镜像），服务间通过网络API通信。这种“进程级模块化”从根本上避免了类加载器冲突、版本管理等问题，代价是增加了分布式系统复杂性。与JPMS或OSGi相比，微服务的模块边界更硬，但通信开销更大。在单体应用内部，JPMS仍然有助于改善代码结构和可维护性。
JPMS的未来在于与工具链的深度集成。Maven和Gradle已经支持多模块项目与JPMS协同，IntelliJ IDEA和Eclipse提供了module-info的编写辅助。Java 17之后的版本继续完善JPMS，例如增加了对密封类的支持。此外，GraalVM native image对JPMS也有一定支持，可以编译模块化为独立可执行文件https://190086.com。
对于新项目，建议从设计上考虑模块化，但不一定急于引入module-info。可以先采用包级别封装（包私有类），并使用构建工具的多模块项目进行物理隔离。当项目规模变大，需要严格控制依赖关系时，再添加module-info。对于库开发者，提供模块化的JAR（包含module-info）可以提高兼容性。
总之，Java模块化的演进反映了从技术实现到架构思想的变迁。OSGi为模块化积累了经验，JPMS提供了官方标准，微服务则改变了模块化的粒度。开发者应根据项目规模、团队能力和部署环境选择合适的模块化策略。
