25

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?

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Alex. S.
  • 143,260
  • 19
  • 55
  • 62

9 Answers9

71

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 no one 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.

(added in 2021) This is even more important nowadays when this type of package naming is used for third-party libraries which are pulled in transitively during builds and could easily conflict if the names were not unique. If everyone adheres to the same convention, there will be no accidental collisions.

(added in 2021) The same naming convention can be used for application ids on an app store to ensure uniqueness as well.

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

Scott Stanchfield
  • 29,742
  • 9
  • 47
  • 65
  • 13
    I like this approach so much that it has often left me wondering why domain names are the order they are. The paths on a host go from general->specific, but subdomain.domain.tld goes specific->general. Inconsistency... must refactor... – rmeador Oct 09 '08 at 21:30
  • Since programming came first before internet (www explosion), rather internet URL addressing scheme should have been known to be using reverse package/namespace naming scheme instead. Incidentally, it just the vice versa :P. – RBT Nov 18 '16 at 02:25
21

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

Ben Hoffstein
  • 102,129
  • 8
  • 104
  • 120
5

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.

Cyphus
  • 793
  • 5
  • 16
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.

NotMe
  • 87,343
  • 27
  • 171
  • 245
  • 1
    The com part makes sure the package name is unique. Different companies may own the .com, .net, .org etc. domains. – Dan Dyer Oct 09 '08 at 22:09
  • 1
    Plus country codes -- au.com.blahblah... – Andrew Oct 14 '08 at 09:17
  • 2
    To make the name unique, I see that there no need to make that way. "com.mycompany.myapp" is kinda weirdo for me, useless. It might be "mycompany.com.myapp". It would resolve the uniqueness purpose also avoiding the weirdness. +1 for thinking out of that shaped box. – Cesar Mar 28 '18 at 21:13
4

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
oxbow_lakes
  • 133,303
  • 56
  • 317
  • 449
3

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

LizB
  • 2,193
  • 16
  • 17
  • 1
    This is a crime :) Standard MS namespace does not start with com.* or org.*, it is CompanyName.Utils.* or CompanyName.UI.Extensions.*. A company name perfectly separates code and packages without com.* prefix. – Artur A Sep 03 '18 at 20:29
  • 1
    @Artru That's why Java developers are thinking Microsoft people are silly who don't use com and org to achieve uniqueness. But the need of the uniqueness of a single company with 2 tld is dubious. – Gqqnbig Jul 22 '19 at 06:39
2

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.

Michael Easter
  • 23,733
  • 7
  • 76
  • 107
1

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.

James Schek
  • 17,844
  • 7
  • 51
  • 64
1

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.

Heat Miser
  • 19,438
  • 7
  • 35
  • 38