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

Question

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?

Answer 1

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

Answer 2

Yes, I use the reverse domain for the the start of the package, followed by the other administrative information (projects, departments, etc). The use of the domain minimizes the chance of collisions between vendors/companies/FOSS projects. My "data" package will not collide with another company's data package thanks to the domain.

I have also used the convention of dropping the tld for internal work or classes that are not meant for outside use (maybe undocumented support libraries, etc). This usually makes it clear to other developers that different rules or policies may apply to a block of code.

Using the reverse domain is a lot less chaotic than arbitrary namespaces that don't follow any rules or established pattern.

Answer 3

If it's just an internal project, and the code is unlikely to ever be reused, then I'd usually go with short, descriptive names.

However, if the code is to be used externally or reused in another project, then I tend to go with the reversed domain scheme. It makes sure there won't be any package name clashes.

Answer 4

I do this for all my projects, I've even taken it across to my .NET applications for namespaces.

Answer 5

I find it pretty silly myself. The com. part really adds nothing but 4 extra characters. Also, I think using the company name in the assembly / project name is also wrong. I've worked at too many places that merged with another company or simply renamed itself.

Answer 6

Yes, I've even devised a scheme to create namespaces in JavaScript using the reverse domain naming convention, it makes finding specific assets and what they are responsible for much easier, and it helps to prevent name collisions.

Answer 7

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

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 most general (com, org, net...) to less general (company name) to more specific (project/product/lib name)

Answer 8

It is very useful and copied by others (e.g. XML Schema).

It is useful in the 'large' (given the WWW) but perhaps more so across departments (i.e. in the small). It may seem bloated for smaller projects but it acts like insurance: it's there when you need it later.

Answer 9

I think that this depends greatly on what sort of software is being written. For example, I develop internal systems for a small company, so I choose:

[company].[project].[sub].xyz(.abc)

Where sub is usually one of client, common and server. If I was working in a (commercial) software company, I'd be a lot more reluctant to use the project bit because it's likely that what the app was called when the project started and what it is called when it finished are two completely separate things! Here's to:

oak.lang.Object