modules - ¿Cómo debo nombrar mi módulo Java 9?
java 9 modules (2)
Creo que obtuvimos una writes "oficial" de Mark Reinhold:
Recomienda encarecidamente que todos los módulos se nombren de acuerdo con la convención de nombre de dominio de Internet inversa. El nombre de un módulo debe corresponder al nombre de su paquete principal de API exportado, que también debe seguir esa convención. Si un módulo no tiene dicho paquete, o si por razones heredadas debe tener un nombre que no corresponde a uno de sus paquetes exportados, su nombre debe comenzar por lo menos con la forma invertida de un dominio de Internet con el que el autor está asociado.
Supongamos que tengo una biblioteca con groupId = org.abc y artifactId = myLibrary . ¿Cuál es el nombre recomendado para el nombre del módulo: myLibrary u org.abc.myLibrary ? ¿Hay alguna guía oficial para un esquema de nombres?
Durante un tiempo hubo dos opiniones diferentes sobre su pregunta, pero durante el desarrollo del sistema de módulos, la comunidad optó por el enfoque de DNS inverso.
Nombres de módulos únicos - DNS inverso
Aquí, se supone que los nombres de los módulos deben ser globalmente únicos. Dado ese objetivo, la forma más pragmática de llegar allí es seguir la estrategia de denominación de paquetes y revertir el nombre de dominio con el que están asociados los mantenedores. El estado del sistema de módulos dice esto :
Los nombres de módulos, como los nombres de paquetes, no deben entrar en conflicto. La forma recomendada de nombrar un módulo es usar el patrón de nombre de dominio inverso que ha sido recomendado durante mucho tiempo para nombrar paquetes.
Además, Mark Reinhold writes :
Recomienda encarecidamente que todos los módulos se nombren de acuerdo con la convención de nombre de dominio de Internet inversa. El nombre de un módulo debe corresponder al nombre de su paquete principal de API exportado, que también debe seguir esa convención. Si un módulo no tiene dicho paquete, o si por razones heredadas debe tener un nombre que no corresponde a uno de sus paquetes exportados, su nombre debe comenzar por lo menos con la forma invertida de un dominio de Internet con el que el autor está asociado.
Esto es bastante claro y compartido por otros expertos en Java como Stephen Colebourne .
Los módulos son más grandes que los artefactos
Por un tiempo (principios de 2016) hubo otra recomendación para hacer las rondas. El equipo de JDK declaró que los nombres de los módulos podrían no tener que ser únicos después de todo "porque los módulos son más abstractos que los artefactos que los definen". Mark Reinhold escribe :
Elija los nombres de los módulos que comienzan con el nombre de su proyecto o producto. Los nombres de módulos (y paquetes) que comienzan con nombres de dominio invertidos tienen menos probabilidades de entrar en conflicto, pero son innecesariamente detallados, comienzan con la información menos importante (por ejemplo,
com,orgonet) y no leen bien después de cambios exógenos, como donaciones de código abierto o adquisiciones corporativas (por ejemplo,com.sun.*).El enfoque de nombre de dominio invertido fue sensato en los primeros días de Java, antes de que tuviéramos herramientas de desarrollo lo suficientemente sofisticadas para ayudarnos a lidiar con el conflicto ocasional. Ahora contamos con estas herramientas, por lo que es preferible continuar con la legibilidad superior de los nombres de paquetes cortos y módulos que comienzan con nombres de proyectos o productos, a la verbosidad onerosa de aquellos que comienzan con nombres de dominio invertidos.
Además, tener nombres de módulos que no incluyan un dominio permitiría intercambiar ese módulo por otra implementación siempre que tenga el mismo nombre (e implemente la misma API pública, por supuesto).
En el correo señalado arriba, Reinhold documenta su cambio de opinión:
Algunas personas pueden preferir nombres más cortos y orientados a proyectos, y esos pueden ser adecuados para usar en proyectos limitados que nunca verán la luz fuera de una sola organización. Sin embargo, si crea un módulo que tenga incluso una pequeña posibilidad de ser de código abierto en el futuro, lo más seguro es elegir un nombre de DNS inverso al principio.
Resumen
El jurado está presente y todos los que hicieron pública su opinión están de acuerdo en utilizar DNS inverso para paquetes.