sintaxis reutilizacion paquetes paquete organizacion nombre lista creacion java naming-conventions

reutilizacion - Error de la convención del nombre del paquete java



reutilizacion de paquetes en java (6)

Solo estoy subiendo en la curva de aprendizaje para Java SE y no tengo ningún problema con la convención de Java habitual para nombres de paquetes, por ejemplo, com.example.library_name_here.package_name_here

Excepto.

Me he dado cuenta de una falla al cumplir con esto en algunos paquetes bastante conocidos.

  • JLine : jline.*
  • JACOB : com.jacob.* (No hay jacob.com)
  • JNA : com.sun.jna.* (El descargo de responsabilidad en el sitio dice NOTA: Sun no patrocina este proyecto, aunque el nombre del paquete (com.sun.jna) podría implicar lo contrario).

Entonces, me pregunto, ¿hay casos en que la convención habitual de nombres de dominio reverso se rompa y hay buenas maneras de evitarlo? Los únicos casos que puedo pensar giran en torno a cuestiones de propiedad de nombres de dominio (por ejemplo, cambias el nombre del alojamiento / dominio del proyecto, o ya hay un paquete conocido que tiene "derechos de ocupante" para tu dominio o se ejecuta el dominio del dominio). y alguien más lo saca).

editar: si utilizo el nombre de dominio de mi empresa, y somos comprados o tenemos un spin-off, ¿qué deberíamos hacer con los nombres de los paquetes? mantenerlos igual o cambiar el nombre? (Supongo que cambiar de nombre es malo desde el punto de vista de que las clases compiladas que hacen referencia al paquete pierden)


Es una convención de nombres. No existe ningún requisito real o incluso la expectativa de que el nombre del paquete se corresponda con un nombre de dominio.


La idea general es que dos organizaciones no poseerían el mismo dominio, por lo que usar el nombre de dominio como parte del paquete garantiza que no haya conflictos de nombres. Esta es solo una recomendación sin embargo.

Hay una buena razón para que alguien tenga paquetes en el espacio de nombres del sol. Si proporcionan una implementación de una API pública, a menudo es necesario implementar las clases en el espacio de nombres de la API.


Lo único que importa (en mi humilde opinión) es que las partes del nombre del paquete están "ordenadas" por importancia, es decir, que no termina con gui.myprog, util.myprog, main.myprog pero con myprog.gui, myprog .util y myprog.main No importa si el nombre del paquete realmente comienza con un dominio de nivel superior seguido de un nombre de dominio.


Los paquetes se utilizan para evitar la ambigüedad y las colisiones entre los componentes creados por varias entidades. Mientras siga la convención, y nadie use ilícitamente su sector del pastel del espacio de nombres del paquete, no deberá preocuparse por lo que otros hayan usado.


No puede usar palabras clave de idioma como partes de un nombre de paquete, ese es otro caso donde la convención de nombre de dominio no se puede aplicar: mala suerte para LONG Building Technologies

Pero entonces, la convención es solo eso, una convención, y prácticamente la única razón por la que existe es que minimiza la posibilidad de que diferentes proyectos elijan accidentalmente el mismo nombre de paquete. Si no puedes seguirlo, no es realmente un gran problema.


Si avanza por la curva de aprendizaje de Java, me preocuparía más por hacer que su estructura de empaquetado sea más clara para que pueda encontrar fácilmente la clase que está buscando.