Do you really use your reverse domain for package naming in java?

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).

I actually think the reverse domain name package naming is one of the more brilliant conventions in Java.