Каково значение обратного доменного имени для структуры пакета Java

Question

Почему мы используем обратное доменное имя, например com.something. или орг.что-то. структура для пакетов Java? Я понимаю, что это приносит какую-то уникальность, но зачем нам эта уникальность?

Answer 1

О том, почему мы делаем все наоборот: представьте, что у вас есть два важных пакета: пакет учета и графический пакет. Если вы указали их в «прямом» порядке:

accounting.mycompany.org
graphics.mycompany.org

Тогда это означает, что существует основной пакет accounting, подраздел которого предназначен для mycompany, а подраздел , который называется пакетом org, который вы фактически используете. Тем не менее, вы хотите это:

org.mycompany.accounting
org.mycompany.graphics

Это имеет больше смысла. Из всех пакетов от организаций (org) вы рассматриваете, в частности, mycompany, и в нем есть два подпакета: accounting и graphics.

Answer 2

Глобально уникальные имена пакетов позволяют избежать конфликтов имен между библиотеками из разных источников. Вместо создания новой центральной базы данных глобальных имен используется реестр доменных имен. Из JLS:

Предлагаемая конвенция для Генерация уникальных имен пакетов просто способ совмещать посылку соглашение об именах на вершине существующее, широко известное уникальное имя реестр вместо того, чтобы создавать отдельный реестр для имен пакетов.

Answer 3

Как вы говорите, обратные доменные имена в качестве имени базового пакета гарантируют уникальность.Предположим, что две компании с DN example.com и example.org обе определяют класс Employee в своей структуре.Теперь, если вы используете обе среды, вы не сможете точно определить, какого сотрудника вы хотите использовать в своем коде, но если они определены в пакетах com.example и org.example соответственно, вы можете указать компилятору / JVM, в частности, какой у вас класс.ссылаясь на.Если уникальные пакеты не определены, вы получите ошибки компиляции или ошибки времени выполнения, например, если вы используете класс сотрудника com, но сначала загружается класс сотрудника org из classpath, вы получите ошибку времени выполнения, так как два класса сотрудника могут неимеют одинаковую структуру.

Answer 4

Уникальность необходима для загрузки классов.

Это помогает, избегая именования коллизий. Если существуют классы с одинаковым именем пакета и именем класса, при попытке загрузки классов произойдет столкновение.

Обычно это происходит, если есть несколько библиотек (jar), которые содержат классы с одинаковыми именами.

Также см. это .

Answer 5

Как вы сказали, это приносит уникальность, что необходимо, особенно при работе со сторонним кодом. Например, предположим, что вы используете созданную мной библиотеку. Я использовал пакет "foo" и у меня там есть класс с именем Bar. Теперь, если вы также используете имя пакета "foo" И у вас есть класс с именем Bar, это будет означать, что ваша реализация переопределит мою реализацию Bar, сделав мою реализацию недоступной. С другой стороны, если бы мой пакет был "com.mydomain.foo", и я имел там класс Bar, то вы можете свободно использовать имя Bar в одном из ваших классов, и оба класса все равно можно было бы однозначно идентифицировать и использовать отдельно. .

Зачем использовать обратное доменное имя в качестве имени пакета? Я предполагаю, что это просто соглашение, чтобы убедиться, что все используют уникальное пространство имен, так как вы не должны использовать чужой домен в имени вашего пакета.

Answer 6

Вам нужна уникальность, если вам может понадобиться интегрировать ваш код со сторонним программным обеспечением или предоставить его кому-то еще для интеграции. Если вы не будете следовать правилам, вы увеличите риск того, что в какой-то момент у вас возникнет коллизия именования классов, и вам потребуется переименовать множество ваших классов, чтобы устранить их. Или, что еще хуже, вашим клиентам придется переименовывать код.

Это также применимо, когда код создается в рамках различных проектов в организации.