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

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

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

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

accounting.mycompany.org
graphics.mycompany.org

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

org.mycompany.accounting
org.mycompany.graphics

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

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

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

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

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

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

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

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

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