Java Package Names

Standards for Java package names

If you have your own domain

Start your package names with your domain, reversed. For example, since Ward's domain is c2.com, his packages would all start with com.c2.

If you don't have your own domain

Start your package names with your email address, reversed. For example, since my email address is wconrad@sprintmail.com, my package names would all start with com.sprintmail.wconrad.

Or, host your code at a site which will give you a slice of their domain. For example, if I were to host my code at gjt.org, then my packages would start with org.gjt.wconrad.

Note that sourceforge (http://sourceforge.net) has now given permission for Java developers to use com.sourceforge.<project> as the package name.

Shouldn't that be net.sourceforge.<project>?

In particular, Sec. 7.7 of the Java Language Specification http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html#40169 doesn't say anything about email address, but it is a good convention.

Actually, it motivates people to register domain names for their projects. I own renew.de primarily for the purpose of having a nice Java package name for my pet project. -- OlafKummer

I always thought that this pattern for generating package names is shortsighted. It looks nice first, but cannot really carry you through. How for example should today's regular mergers and renamings of companies be handled? Touch all sources? Or leave them and try to remember whether you have to use com.daimler, com.chrysler or com.daimlerchrysler? And Sun did not hold onto it from the beginning too: Or how should they own the top-level domains .java and .javax? And what should happen if there would be TLDs .java and .javax in the future and somebody actually has the domain lang.java?

::How many projects are named after the company? Many Projects have their own domains.

As I said: Nice idea, at first sight.

-- MarkoSchulz

Complaining is easy. What's your proposal?

How about:

 package md5.b0aafe05fc46ae69dca469ec10fc353b ;

HaHaOnlySerious - think MicroSoft CLSIDs.

A better solution might be to allow aliasing - for instance, when Foo Corp buys Bar Systems, they set up an alias from com.foo to com.bar, or move the code from com.bar to com.foo and set up an alias under com.bar (or whatever - this would probably be too broad). Where the code is in JAR files (a fairly common case), this could be done with entries in the META-INF directory. The compiler might consider aliased names to be deprecated, and so warn programmers when they used them. Note that this would also have eased the pain of the SwingNamespaceTransition?.

The problem of name change over time is more serious for email addresses; I used to be thomas.anderson@univ.ox.ac.uk, now I'm thomas.anderson@imm.ox.ac.uk, and soon I'll probably be tanderson@ucl.ac.uk. Meanwhile, I am also tanders@molbiol.ox.ac.uk (my account on the bioinformatics BigIron), twic@urchin.earth.li and a variety of other names, none of which are really permanent. The TagUri approach could solve this problem.

-- TomAnderson (OpenAuthor; signing to make clear it's not MarkoSchulz writing)

I am so lucky that I have stayed in the same job for a long time and so my email address has not changed for years. It does have aliases and I discovered recently that it is aliased to the original email address I was assigned when we were first allocated codes many years ago. -- JohnFletcher

See: CreatingJavaPackages

CategoryJavaPlatform