java package name convention failure

I'm just coming up the learning curve for Java SE & have no problem with the usual Java convention for package names, e.g. `com.example.library_name_here.package_name_here` Except. I've been noticing a failure to abide by this in some fairly well-known packages. - [JLine][1]: `jline.*` - [JACOB][2]: `com.jacob.*` (there is no jacob.com) - [JNA][3]: `com.sun.jna.*` (disclaimer on the site says NOTE: Sun is not sponsoring this project, even though the package name (com.sun.jna) might imply otherwise.) So I'm wondering, are there instances where the usual reverse-domain-name convention breaks down, and there are good ways to get around it? The only cases I can think of revolve around domain-name ownership issues (e.g. you change the project hosting/domain name, or there's already a well-known package that has "squatter's rights" to your domain, or your ownership of the domain runs out & someone else snaps it up). edit: if I use my company's domain name, and we are bought out or have a spin-off, what should we do with package names? keep them the same or rename? (I suppose renaming is bad from the point of view that compiled classes referring to the package then lose) [1]: http://jline.sourceforge.net/ [2]: https://sourceforge.net/projects/jacob-project/ [3]: https://github.com/twall/jna/
JUnit used to make the same mistake, but fixed it in Junit 4 (while still keeping some classes in the old packages for backwards compatibility)

以上就是java package name convention failure的详细内容,更多请关注web前端其它相关文章!

赞(0) 打赏
未经允许不得转载:web前端首页 » JavaScript 答疑

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

前端开发相关广告投放 更专业 更精准

联系我们

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏