No estoy seguro de haberlo hecho bien: java.base es el módulo base subyacente de todos los demás módulos y contiene todas las cosas básicas de ellos, como una superclase de una clase. Y java.se es el módulo que contiene todo el JDK, como una subclase (que contiene la funcionalidad básica y cosas más específicas)
java.base es el módulo base; todos los demás módulos dependen implícita o explícitamente de él:
Si la declaración de un módulo no expresa una dependencia del módulo
java.base[...] entonces el módulo tiene una dependencia implícitamente declarada del módulojava.base.
( Especificación del lenguaje Java 17 §7.7.1 )
java.se "define la API de la plataforma Java SE" (según la documentación). Aproximadamente (?) comprende todas las clases que estaban presentes en Java SE antes de la modularización, excepto que ahora están separadas en diferentes módulos, por ejemplo, java.desktop o java.sql . No incluye módulos específicos de JDK (como jdk.javadoc ). Un tiempo de ejecución de Java podría no proporcionar necesariamente todos estos módulos; por ejemplo, podría usar jlink para crear un tiempo de ejecución de Java que solo contenga los módulos que necesita (como mínimo java.base ).
La especificación de la API de Java también puede ser útil para comprender el contenido de los módulos y sus relaciones:
Su comparación con una clase (módulo java.base ) y su subclase (módulo java.se ) funciona en este caso porque java.se actúa como un módulo 'agregador' que en sí mismo no contiene ni exporta ningún paquete, pero solo tiene indirecta exportaciones a través de requires transitive . Consulte esta pregunta para saber por qué existe el módulo java.se Aunque normalmente no declararía una dependencia en java.se porque eso anula el propósito de crear imágenes de tiempo de ejecución pequeñas personalizadas; en su lugar, solo declararía dependencias en los módulos específicos que realmente necesita, por ejemplo, java.logging .
Sin embargo, estos módulos de agregación son bastante poco comunes. En la mayoría de los casos, los módulos se utilizarán más bien para agrupar paquetes relacionados y restringir el acceso a implementaciones internas. Sin embargo, en estos casos, los servicios definidos por un módulo y el proveedor de servicios correspondiente implementado y declarado por otro módulo son similares a su analogía.