java package name fracaso de la convención

Question

Acabo de llegar a la curva de aprendizaje para Java SE & no tengo ningún problema con la convención de Java habitual para nombres de paquetes, p. com.example.library_name_here.package_name_here

Excepto.

He estado notando una falla al cumplir con esto en algunos paquetes bastante conocidos.

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

Así que me pregunto, ¿hay casos en que la convención habitual de nombre de dominio inverso se descompone, y hay g formas buenas 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). & 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 renombrar es malo desde el punto de vista que las clases compiladas que se refieren al paquete luego pierden)

Answer 1

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.

Answer 2

Lo único que importa (en mi humilde opinión) es que las partes del nombre del paquete están "ordenadas" por importancia, es decir, 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.

Answer 3

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

Answer 4

no puede utilizar palabras clave del lenguaje como partes de un nombre de paquete, eso es otro caso en el que la convención de nombre de dominio no puede ser aplicado - Mala suerte para LONG Building Technologies

Pero entonces, la convención es sólo 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.

Answer 5

La idea general es que dos organizaciones no tendrían el mismo dominio, por lo que usar el nombre de dominio como parte del paquete garantiza que no haya conflictos de espacio 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.

Answer 6

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