包命名空间 - 与反向域名命名方案

问题描述：

我已经注意到，有几个类型安全的附属项目，如spray和akka，不包括com.或org.因为他们明确规定了包名的开始。包命名空间 - 与反向域名命名方案

我想知道是否存在这种偏离Java的“反向域”包命名方案的技术含义。 java互操作性有没有可能的影响？在我自己的库和包中跳过scala包名称中的com/org组件的技术含义可能是什么？

当然，反向域方案通过将名称空间链接到Internet注册服务商独有的资源来减轻包名称空间冲突的问题，因此解散该模型的项目没有这种保护措施，但我不会严格地将其称为技术含义，所以我们可以忽视...

顺便说一句，http://docs.scala-lang.org/style/naming-conventions.html排序的建议坚持反向域命名，但可能它已过时。 – matanster

没有遵循反向域指南的scala没有技术兼容性问题..遵循它的同样的问题也没有在Java中升起。通常的观点是，长包名称很吸引人，为什么每当公司更改名称时都浪费时间更改每个源文件，以及为什么会浪费时间更改每个源文件与您已经观察到的冲突风险。 –

你已经在两天前询问（并删除了）这个问题http://*.com/questions/33190124/package-namespaces-in-scala-and-the-reverse-domain-naming-scheme –

答

的反向域名方案缓解包命名空间冲突的问题

这是该计划的唯一原因，这应该回答y我们的问题。我知道，特别是在包结构中互操作性的唯一问题是Scala包名可以包含Java（and Scala, using backticks）关键字。

虽然超出了问题的范围，但是您能否简要地介绍最差情况下的互操作性方案？ – matanster

为此，仅仅是您无法从Java代码中访问此类包中的类型（忽略反射）。 –