包命名空間 - 與反向域名命名方案

我已經注意到，有幾個類型安全的附屬項目，如spray和akka，不包括com.或org.因爲他們明確規定了包名的開始。包命名空間 - 與反向域名命名方案

我想知道是否存在這種偏離Java的「反向域」包命名方案的技術含義。 java互操作性有沒有可能的影響？在我自己的庫和包中跳過scala包名稱中的com/org組件的技術含義可能是什麼？

當然，反向域方案通過將名稱空間鏈接到Internet註冊服務商獨有的資源來減輕包名稱空間衝突的問題，因此解散該模型的項目沒有這種保護措施，但我不會嚴格地將其稱爲技術含義，所以我們可以忽視...

2015-10-20 matanster

順便說一句，http://docs.scala-lang.org/style/naming-conventions.html排序的建議堅持反向域命名，但可能它已過時。 – matanster

沒有遵循反向域指南的scala沒有技術兼容性問題..遵循它的同樣的問題也沒有在Java中升起。通常的觀點是，長包名稱很吸引人，爲什麼每當公司更改名稱時都浪費時間更改每個源文件，以及爲什麼會浪費時間更改每個源文件與您已經觀察到的衝突風險。 –

你已經在兩天前詢問（並刪除了）這個問題http://stackoverflow.com/questions/33190124/package-namespaces-in-scala-and-the-reverse-domain-naming-scheme –

的反向域名方案緩解包命名空間衝突的問題

這是該計劃的唯一原因，這應該回答y我們的問題。我知道，特別是在包結構中互操作性的唯一問題是Scala包名可以包含Java（and Scala, using backticks）關鍵字。

2015-10-20 17:34:35

雖然超出了問題的範圍，但是您能否簡要地介紹最差情況下的互操作性方案？ – matanster

爲此，僅僅是您無法從Java代碼中訪問此類包中的類型（忽略反射）。 –

回答