The practice is extremely useful because it provides a decentralized system for namespacing software. There is no need to apply to a centralized agency for a namespace; simply use the domain name you own (reversed) and manage that within your own organization. By naming packages like this, one can be almost certain that code won't conflict with other packages.
From Oracle's Java Tutorials:
Companies use their reversed Internet domain name to begin their package names
for example, com.example.mypackage for a package named mypackage created by a
programmer at example.com.
Name collisions that occur within a single company need to be handled by
convention within that company, perhaps by including the region or the
project name after the company name (for example,
It's more than a rote practice, it's good practice because it's a complete and fully specific namespace. If there were two companies named Acme and both chose the namespace
acme., their code would conflict. But only one of those companies can own the domain acme.com, so they get to use the
Reversing the domain name allows for a top-down architecture.
com would contain code for companies (or anyone who owns own a .com domain name), and underneath that would company (domain) names. Then, deeper within that would be the structure of the organization and/or the actual namespace. (For example, if it was code from a network called internal.acme.com, that gives this department their own sub-namespace of
com.acme.) This top-down structure is used in a number of applications, including in systems administration. (It's similar to reverse IP address lookups.)
com.digitalfruition. can get a bit much) but that can easily be worked around with a closure and a local variable (
var DF = com.digitalfruition).