Что такое соглашение для имен пакетов 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.

Если вы собираетесь распространять много материала, я бы действительно предложил получить доменное имя. Другой альтернативой, однако, будет использование вашего электронного письма: например, 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 – зарезервированный домен верхнего уровня)

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