我剛剛爲Java SE提供了學習曲線&對於軟件包名稱的常規Java約定（例如， com.example.library_name_here.package_name_hereJava軟件包名稱約定失敗
除外。
我一直在注意到在一些相當知名的軟件包中沒有遵守這一點。
所以我想知道，是否有通常反向域名約定中斷的情況下，有g它的方式來解決它？我能想到的唯一情況是圍繞域名所有權問題（例如，您更改了項目託管/域名，或者已經有一個知名的軟件包對您的域擁有「擅自佔有權」，或者您擁有域出&別人把它收起來）。
編輯：如果我使用我公司的域名，並且我們被收購或分拆，我們應該如何處理包名？保持不變或重命名？ （我認爲重命名是不好的，因爲編譯指向包的類會丟失）
軟件包用於避免由各種實體構建的組件之間的不明確性和衝突。只要你遵守約定，並且沒有人非法使用你的包命名空間派的片斷，你不應該擔心別人使用了什麼。
唯一重要的事情是（IMHO），包名的部分按重要性「排序」，即你不會以gui.myprog，util.myprog，main.myprog結尾，而是使用myprog.gui，myprog.util和myprog.main。包名是否真正以頂級域名後跟一個域名開頭對我來說無關緊要。
實際上，重要的是它們不會相互碰撞，因此您必須聲明一些在名字上。使用Jline *是不健康的，因爲如果其他人很愚蠢，你的申請不能一起使用。 – 2009-01-07 18:15:41
這是一個命名約定。沒有真正的要求，甚至不希望軟件包名稱映射到域名。
但是，有一個非常強烈的建議。 – 2009-01-07 16:32:16
@sblundy，不，實際上，它絕對存在*期望*（不要求），它映射到域名。沒有人會看到com.name.product，並考慮是否是name.com或name.org（公司）。他們（我們都）假設name.com。 – 2015-01-25 20:20:12
你無法用語言的關鍵字作爲包名的一部分，這就是域名約定不能適用另一種情況 - 倒黴的LONG Building Technologies
但隨後，該公約是僅僅是一個慣例，幾乎所有存在的唯一原因是它最大限度地減少了不同項目意外選擇相同包名的機會。如果你不能遵循它，這不是一個真正的大問題。
總體思路是兩個組織不會擁有相同的域，因此將域名用作包的一部分可確保不存在名稱空間衝突。但這只是一個建議。
有人有一個很好的理由讓軟件包在sun名稱空間中。如果他們提供公共API的實現，通常需要在API的名稱空間中實現這些類。
如果您正在通過Java學習曲線，我會更加關注如何使您的包裝結構變得清晰，以便您可以輕鬆找到所需的課程。
JUnit曾經犯過同樣的錯誤，但在Junit 4中修正了它（同時爲了向後兼容性而在舊包中保留了一些類） – 2009-01-07 16:28:41