What's the convention for java package names without a domain association?

I can't find a Q/A on SO that answers my exact question, so I figure I'd post it and see what comes back.

As far as the naming convention goes for Java packages, I understand that it's supposed to be the reverse domain name: com.whatever.stuff and I get the rules about no mixed case, hyphens, keywords, etc.

I've also read section 7.7 (Unique-Package-Names) of the Java Language Specification. As far as I can tell, the rules from Java are to use the reverse domain to insure uniqueness... and if you don't have one, go get one:

You form a unique package name by first having (or belonging to an organization that has) an Internet domainname, such as sun.com. - Section 7.7

So if I'm not interested in shelling out the money for a domain name, I don't belong to a company whose name I can piggyback off of, is there any part of the naming convention that I'm missing that should be followed? I'm thinking I can just go name it whatever unique name I feel like at this point, but I was just wondering if I was missing anything.

Note: I would like to release my package for other developers to use, so I didn’t want to just do something that worked on my system, but something more standard if possible.

I added the android tag because the java packages I'm going to be writing are going to be used in an Android application, wasn't sure if there were different opinions from android developers.

If you are going to be distributing a lot of stuff, I would really suggest getting a domain name. Another alternative however would be to use your e-mail: e.g. [email protected] would become com.gmail.bob. This is less common than using domain names but is still done by some and still ensures uniqueness.

One convention is to use the domain name of the hosting provider, e.g.

com.github.myrepositoryname
net.sf.sourceforge.myproject
com.googlecode.myproject

Benefits:

• your package namespace will be unique, since the hosting provider won't have two projects of the same name
• it's only as expensive as the host's costs, many of which are free
• it can be an easy way to fulfil Sonatype's requirements if you want to get your project into Maven Central

Drawbacks:

• if you decide to change providers, you either have package structures which are out-of-date, or you introduce backward-incompatible changes to keep the source in line with your new provider