For a long time ago, I have thought that, in java, reversing the domain you own for package naming is silly and awkward.
Which do you use for package naming in your projects?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
For a long time ago, I have thought that, in java, reversing the domain you own for package naming is silly and awkward.
Which do you use for package naming in your projects?
Once you understand why the convention exists, it shouldn’t feel silly or awkward in the least.
This scheme does two important things:
All of your code is contained in packages that no one else will collide with. You own your domain name, so it’s isolated. If we didn’t have this convention, many companies would have a "utilities" package, containing classes like "StringUtil", "MessageUtil" etc. These would quickly collide if you tried to use anyone else’s code.
The "reverse" nature of it makes class-directory layout very narrow at the top level. If you expand a jar, you’ll see "com", "org", "net", etc dirs, then under each of those the organization/company name.
(added in 2021) This is even more important nowadays when this type of package naming is used for third-party libraries which are pulled in transitively during builds and could easily conflict if the names were not unique. If everyone adheres to the same convention, there will be no accidental collisions.
(added in 2021) The same naming convention can be used for application ids on an app store to ensure uniqueness as well.
We usually don’t expand jars, but in early java development, this was important because people used expanded dir structures for applets.
However, this is nice now as source code dir structures have a very "top-down" feel. You go from the most general (com, org, net…) to less general (company name) to more specific (project/product/lib name).