Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as primarily opinion-based by gnat, Kilian Foth, Bart van Ingen Schenau, MichaelT, GlenH7 Aug 15 at 13:45

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
We're all familiar with the Java package name convention of turning the domain name around. - um..no we're not... :) –  dr Hannibal Lecter Nov 27 '10 at 20:47
7  
@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. –  doppelgreener Nov 28 '10 at 11:33
3  
@dr Hannibal Lecter: Cf. docs.oracle.com/javase/tutorial/java/package/namingpkgs.html –  user359996 Sep 20 '12 at 20:37

5 Answers 5

up vote 15 down vote accepted

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.

share|improve this answer
3  
What do Microsoft recommend you do if another company has the same name as yours? –  user1249 Nov 28 '10 at 21:15
8  
@Thorbjørn - litigation –  RevBingo Nov 28 '10 at 22:09
2  
@RevBingo, bad solution. Who belongs e.g. "Prodata" to? prodata.com, prodata.dk or prodata.se? –  user1249 Nov 28 '10 at 22:30
5  
@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. –  Allon Guralnek Nov 29 '10 at 8:00
4  
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 '12 at 20:35

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.

share|improve this answer
    
+1 "You are looking at the solution to a different problem." –  user359996 Sep 20 '12 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.
share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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