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?

  • 2
    We're all familiar with the Java package name convention of turning the domain name around. - um..no we're not... :) Nov 27, 2010 at 20:47
  • 9
    @dr Hannibal Lecter: Pretty simple. Java (at the site Java.com) names their packages com.java.etc.etc. Apache (at the site Apache.org) names their packages org.apache.etc.etc. You see the pattern. Nov 28, 2010 at 11:33
  • 3
    @dr Hannibal Lecter: Cf. docs.oracle.com/javase/tutorial/java/package/namingpkgs.html
    – user359996
    Sep 20, 2012 at 20:37
  • 3
    "In the opensource world there's less name changes" -- even there it's a problem, often I see projects that are now on say github but their package names reveal that they used to be at the reverse of net.sourceforge.xxx or com.googlecode.xxx
    – nafg
    May 22, 2016 at 4:10
  • 1
    In my mind, it's not necessarily the issue that you have a domain implicit in the package name. It's that it's not a variable. So when it changes, you would need to change it in hundreds, if not thousands of places. Thinking out loud, one solution would just have the compiler optionally understand something like com.${domain}.package, where the domain is supplied externally. Feb 20, 2018 at 16:27

5 Answers 5


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:


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.

  • 3
    What do Microsoft recommend you do if another company has the same name as yours?
    – user1249
    Nov 28, 2010 at 21:15
  • 26
    @Thorbjørn - litigation
    – RevBingo
    Nov 28, 2010 at 22:09
  • 9
    @Thorbjørn: A namespace, unlike a domain, isn't, and can't be owned by anyone. It is only a logical division or categorization of code. The chances of collision between you and that other company approaches zero, unless that other company also happens to develop software, in the same technology, and has a similar offering (in short - a competitor of yours). In that case, I'd take RebBingo's suggestion, unless you're okay with having a competing company that has the same name as your company. Nov 29, 2010 at 8:00
  • 5
    As pointed out in @Thorbjørn's answer, the problem the Java naming convention solves for is not guaranteeing constancy but rather guaranteeing uniqueness. Note the Microsoft convention guarantees neither.
    – user359996
    Sep 20, 2012 at 20:35
  • 4
    @user359996: Like I said, I don't see why universal uniqueness is a problem that needs solving. Why would you need names to be unique across mutually exclusive code bases? And Java's style doesn't guarantee it, since domain names ownership can switch hands. A developer who owns jUtils.com can develop a com.jutils.* library that many use, and then sell his domain to a completely different developer who develops a different com.jutils.* library which is also popular, but has collisions with the existing library. Sep 21, 2012 at 10:57

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.

  • +1 "You are looking at the solution to a different problem."
    – user359996
    Sep 20, 2012 at 20:31

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.

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:




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


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.