¿Por qué los paquetes y módulos son conceptos separados en Java 9?

Java 9 tendrá módulos además de paquetes. Por lo general, los idiomas tienen uno u otro. Y la mayoría de los programadores perciben dos términos como sinónimos. Los módulos están construidos sobre paquetes, tratándolos como primitivos. El patrón compuesto sugiere tratar los primitivos y los compuestos de manera uniforme. De lo contrario, sucederán cosas malas. Por ejemplo, mire el proyecto Valhalla, donde intentan adaptar el supertipo común para primitivo (valor) y tipos de referencia.

¿Los módulos y paquetes representan nociones semánticamente separadas? Lo que significa que es sensato tener ambos para cualquier idioma (separación de preocupaciones). ¿O Java tiene que tener ambos como tributo a la compatibilidad con versiones anteriores?

¿Por qué introducir un nuevo concepto en lugar de aumentar el existente?

JSR 376 : "Sistema de módulo de plataforma Java" implementado dentro del proyecto Jigsaw .

De acuerdo con SOTMS

Un módulo es una colección de código y datos con nombre y autodescripción. Su código está organizado como un conjunto de paquetes que contienen tipos, es decir, clases e interfaces Java; Sus datos incluyen recursos y otros tipos de información estática.

JLS evita cuidadosamente definir qué es un paquete . De Wikipedia :

Un paquete de Java es una técnica para organizar clases de Java en espacios de nombres similares a los módulos de Modula, proporcionando programación modular en Java.

Sé que citar Wikipedia es una mala práctica, pero refleja un entendimiento común. Desde la entrada en programación modular:

El término paquete a veces se usa en lugar de módulo (como en Dart, Go o Java). En otras implementaciones, este es un concepto distinto; en Python, un paquete es una colección de módulos, mientras que en el próximo Java 9 se planea la introducción del nuevo concepto de módulo (una colección de paquetes con control de acceso mejorado).

El concepto de un módulo es diferente de la instanciación de ese concepto.

Java siempre ha tenido módulos. Un método es un módulo, también lo es una clase y también un paquete. Un módulo es una unidad de organización en la que se ocultan los detalles internos, y que se comunica con otros módulos a través de contratos acordados. Por ejemplo, un método es un módulo porque tiene elementos internos ocultos (el código y las variables locales) y un contrato (los parámetros y el tipo de retorno). Los módulos pueden estar compuestos de módulos de nivel inferior, por ejemplo, las clases contienen métodos.

Lo que falta en el núcleo de Java (pre-9) es un módulo desplegable . Todos los tipos de módulos anteriores no son unidades desplegables que se puedan copiar. Java tiene un artefacto desplegable llamado archivo JAR, pero estos no son módulos porque no tienen encapsulación o contrato: en tiempo de ejecución los archivos JAR desaparecen, todos se fusionan en un solo "classpath".

OSGi abordó la falta de módulos desplegables en 1998 con el concepto de un "paquete". Estos son archivos JAR físicamente y contienen paquetes, pero OSGi define metadatos adicionales junto con un sistema de tiempo de ejecución para admitir la encapsulación y los contratos a ese nivel.

Java 9 aborda la falta de módulos desplegables de manera similar a OSGi. Podría decirse que esto era completamente innecesario porque OSGi existe y funciona, pero esa es una discusión completamente diferente ...

Desafortunadamente, Java 9 enturbia las aguas al nombrar el nuevo concepto de módulo solo como un "módulo". ¡Esto no significa que los métodos, clases y paquetes dejen de ser módulos! Un "módulo" J9 es solo otra instancia del concepto de módulo . Al igual que los paquetes OSGi, los módulos J9 están hechos de paquetes y son artefactos físicos (generalmente archivos JAR nuevamente) que se pueden copiar. El sistema de tiempo de ejecución los comprende y los reifica.

Resumen: sí, los módulos y paquetes J9 son nociones semánticamente separadas. Obviamente, Java tiene que conservar su concepto de paquete existente para la compatibilidad con versiones anteriores. Tenga en cuenta que la palabra "paquete" se usa de manera bastante diferente en Java que en otros lenguajes o en sistemas de administración de paquetes como RPM. Los nuevos módulos J9 (y los paquetes OSGi) se parecen mucho más a los paquetes en RPM que a los paquetes Java.

Permítanme arriesgarme con una respuesta, aunque gran parte puede ser suposiciones / división de pelos / despotricar, etc.

¿Son la misma cosa? Bueno si ^_y no

De este artículo de JavaWorld sobre "Modularidad en Java 9" :

Paquetes como solución modular

Los paquetes intentan agregar un nivel de abstracción al panorama de programación Java. Proporcionan facilidades para espacios de nombres de codificación únicos y contextos de configuración. Sin embargo, lamentablemente, las convenciones de paquetes se eluden fácilmente, lo que a menudo conduce a un entorno de acoplamientos peligrosos en tiempo de compilación.

Como @ user2418306 (OP) insinuó, " módulos son paquetes bien hechos " . Los módulos y paquetes en Java (a partir de Java 9, obviamente) son (como pregunta OP) semánticamente lo mismo. Es decir, son colecciones de bytecode JVM precompilados, con otros metadatos , esencialmente , son bibliotecas .

Bueno, cual es la diferencia?

Sin embargo, la diferencia está en los metadatos dentro de cada uno de ellos. Los packagemanifiestos de Java , o los manifiestos JAR, a menudo no son mantenidos por los desarrolladores de la biblioteca, ni proporcionan ningún contrato seguro sobre lo que proporciona el paquete JAR /. Como se explica aquí (artículo de JavaWorld nuevamente) :

¿No son los archivos JAR lo suficientemente modulares?

Los archivos JAR y el entorno de implementación en el que operan mejoran en gran medida las numerosas convenciones de implementación heredadas que de otro modo estarían disponibles. Pero los archivos JAR no tienen unicidad intrínseca, aparte de un número de versión poco utilizado, que está oculto en un manifiesto .jar. El archivo JAR y el manifiesto opcional no se utilizan como convenciones de modularidad dentro del entorno de tiempo de ejecución Java. Por lo tanto, los nombres de paquetes de clases en el archivo y su participación en un classpath son las únicas partes de la estructura JAR que prestan modularidad al entorno de tiempo de ejecución.

Una queja sobre otros idiomas / entornos, etc.

Otra área discutida en ese artículo son los sistemas como Maven , que administran las dependencias para usted como parte del proceso de compilación. Desde esta página en el sitio de Apache Maven :

Gestión de dependencias:

Maven fomenta el uso de un repositorio central de JAR y otras dependencias. Maven viene con un mecanismo que los clientes de su proyecto pueden usar para descargar cualquier JAR requerido para construir su proyecto desde un repositorio JAR central como el CPAN de Perl. Esto permite a los usuarios de Maven reutilizar los JAR en todos los proyectos y fomenta la comunicación entre proyectos para garantizar que se aborden los problemas de compatibilidad con versiones anteriores.

Ahora para hablar sobre el futuro como si hubiera estado allí

Como mencionó esa página , otros idiomas (como Perl) tienen repositorios de paquetes (como CPAN ). Esta es una tendencia creciente (lo digo porque me da la gana, sin ninguna prueba contundente), durante la última década más o menos. Las herramientas como las gemas de Ruby , PyPi de Python y el administrador de paquetes Node ( npm) se basan en esto para proporcionar una forma coherente de configurar un entorno (desarrollo, construcción, prueba o tiempo de ejecución, etc.) con las cosas correctas (paquetes, módulos, gemas, artilugios, etc.). Una idea (creo) fue " prestada " de los sistemas de distribución Linux® como Debian's apt , RedHat'srpm, etc. (Aunque, obviamente, ha evolucionado al menos una generación y ha hecho que todo esto sea más agradable).

Los módulos Java , aunque no necesariamente agregan nada que no pueda hacer ya, hacen que las herramientas para la gestión de dependencias / paquetes y entornos de compilación automatizados sean MUCHO más fáciles. Si eso hace que los módulos sean "mejores", me niego a decir. :PAG