Что такое соглашение для имен пакетов java без ассоциации домена?

Я не могу найти Q / A на SO, который отвечает на мой точный вопрос, поэтому я полагаю, что опубликую его и посмотрю, что вернется.

Что касается соглашения об именах для пакетов Java, я понимаю, что это должно быть обратное доменное имя: com.whatever.stuff и я получаю правила о не смешанном случае, дефисах, ключевых словах и т. Д.

Я также прочитал раздел 7.7 (Unique-Package-Names) спецификации языка Java. Насколько я могу судить, правила от Java – использовать обратный домен, чтобы обеспечить уникальность … и если у вас его нет, то получите один:

You form a unique package name by first having (or belonging to an organization that has) an Internet domainname, such as sun.com. – Раздел 7.7

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

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

Я добавил тег android, потому что java-пакеты, которые я собираюсь писать, будут использоваться в приложении для Android, не были уверены, были ли разные мнения разработчиков Android.

Solutions Collecting From Web of "Что такое соглашение для имен пакетов java без ассоциации домена?"

Если вы собираетесь распространять много материала, я бы действительно предложил получить доменное имя. Другой альтернативой, однако, будет использование вашего электронного письма: например, bob@gmail.com станет com.gmail.bob . Это реже, чем использование доменных имен, но все еще выполняется некоторыми и по-прежнему обеспечивает уникальность.

Одно из соглашений – использовать доменное имя хостинг-провайдера, например

 com.github.myrepositoryname net.sf.sourceforge.myproject com.googlecode.myproject 

Выгоды:

  • Ваше пространство имен пакетов будет уникальным, поскольку у хостинг-провайдера не будет двух проектов с тем же именем
  • Это так дорого, как затраты хозяина, многие из которых бесплатны
  • Это может быть простой способ выполнить требования Sonatype, если вы хотите получить свой проект в Maven Central

Недостатки:

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

Доменные имена могут быть предоставлены бесплатно. Например, dyn.com предлагает бесплатные доменные имена формы «whatever.dyndns.org» по адресу http://free.domain.name/

В профессиональной среде конвенция заключается в использовании обратного домена. В среде, которая больше связана с вами, вы можете использовать org.projectname.packagename.* .

Это соглашение, а не жесткое правило. Вы можете использовать любой тип имен доменов, который вам нравится.

Если вы единственный кодер, вы можете просто использовать свое имя. Меня зовут Jannis Froese, поэтому я буду использовать

jannisfroese.projectname.stuff

Или если вы хотите остаться с «действительными» доменными именами

localhost.jannisfroese.projectname.stuff

(Localhost – зарезервированный домен верхнего уровня)

Конечно, это работает только в том случае, если ваше имя достаточно уникально, так что столкновение маловероятно