Is the Java package name convention flawed? [closed]

Question

We're all familiar with the Java package name convention of turning the domain name around. I.e. www.evilcorp.com would, by convention, chose to have their java packages com.evilcorp.stuff.

Increasingly I'm getting fed up with this. As a commercial programmer, I encounter time and again that the software package name is completely irrelevant due to some rebrand, acquisition or similar.

In the opensource world there's less name changes so there it makes sense. However it seems to me the shelf life of many pieces of (commercial/internal) software are much longer than that of the organisation making them.

The problem is often made worse by software projects taking the marketing department's lead to use the name du jour they use refer to a certain project. A name that will, without fail, change 3 months down the line to make the emperor's new clothes feel fresh and new.

Because of this, I've mostly stopped using the reverse domain as package name. Granted, if this is done on a large scale, there's risk of name collisions, but surely this is mitigated by either using "unique" software names, avoiding generic words, or use the reverse domain for projects intended to be sold/released as libraries.

Other thoughts?

Answer 1

I'm going to quote the advice Microsoft gives for namespaces (.NET's packages), which doesn't have the domain name convention. I think it's good advice for Java packages too, since I don't believe that a domain name represents a solid and stable identity.

The general format for a namespace name is as follows:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

For example, Microsoft.WindowsMobile.DirectX.

Do prefix namespace names with a company name to prevent namespaces from different companies from having the same name and prefix.

Do use a stable, version-independent product name at the second level of a namespace name.

Do not use organizational hierarchies as the basis for names in namespace hierarchies, because group names within corporations tend to be short-lived.

The namespace name is a long-lived and unchanging identifier. As organizations evolve, changes should not make the namespace name obsolete.

If even your company name is unstable, you might want to just start with the product name.

Answer 2

You are looking at the solution to a different problem, namely how do we avoid that programmer X and programmer Y step on each others toes by putting files in the same package.

The "just reverse your domain name" solve this in an elegant way, as you then are pretty certain that if X and Y are unrelated they will not pick the same package name space.

Answer 3

The convention is not flawed. People are flawed, as you have nicely illustrated yourself.

I can think of 2 benefits:

1. It avoids collision between independent developers. A domain is unique. Two people can name two different project the same, but a domain has exactly one owner.
2. It makes it easier to find the maintainer. If you inherit a code base, that uses some open source library, it better be in a package that helps you find it. By now it doesn't really matter, because you will most certainly be able to google it. But 10 years ago, this wasn't so evident.

Answer 4

The reverse domain name was used to avoid name collisions in case different organizations use the same class names in their libraries. It is a simple solution and off cource has some drawbacks (e.g. what about name collisions for classes in the same organization?).

You are not obligated to use it, it is a convention not a do or die rule. For example, some Java programmers don't respect the Java Code Conventions.

But consider the alternatives. How would you, for example, like two fully qualified class names for a LogFactory:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

or

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

So, in my thoughts, use whatever you like as long as it includes common sense and a consideration for the users of your library.

Answer 5

When I start a new project, I always insist on an internal and unchangeable name that the marketing people may or may not know, as it will only be referred to in the source code. That way, I do not have to worry about project name changes and namespace pollution.

This scenario fits me, because the source code is not usually an important part of the product, i.e. projects are usually a closed-source, proprietary systems. However, in open-source projects where the source code is the product, this might not be feasible.