Develop Reference

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. bob#gmail.com 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

Domain names can be had for free.
For example dyn.com offers free domain names of the form 'whatever.dyndns.org' at http://free.domain.name/

If you are the only coder, you can just use your name.
My name is Jannis Froese, so I would use
jannisfroese.projectname.stuff
or if you want to stay with 'valid' domain names
localhost.jannisfroese.projectname.stuff
(localhost is a reserved top level domain)
Of course this only works if your name is sufficiently unique, so that a collision is unlikely enough

In a professional environment, the convention is to use reverse domain. In an environment that's more associated with yourself, you can use org.projectname.packagename.*.
It's a convention, not a hard and fast rule. You're free to use whichever domain naming style you like.

Why do Java sources have so many folders inside each other?

Every time I look at some Java source code, I find myself surfing in a folder that has folder that has folder that has folder in it etc. Why does Java require so many nested folders, which have nothing else in them except the new subfolder?
For example:
https://github.com/halfninja/android-dragcontrol3d/tree/master/src/uk/co/halfninja/android
That's probably not the worst example, but there are two folders "uk" and "co" that just don't make sense. I see this in Java sources only!
And for example minicraft: http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=398
import com.mojang.ld22.gfx.Font;
import com.mojang.ld22.gfx.Screen;
import com.mojang.ld22.gfx.SpriteSheet;
Why not just write:
import gfx.Font;
import gfx.Screen;
import gfx.SpriteSheet;
That's so much cleaner.
(I have never programmed in Java.)

These are there to prevent conflicts with other jars. Having something like the company url in the package name makes it likely to be unique enough to not conflict with someone else's package and classes.
Your example is a good one, since it seems pretty reasonable to imagine two people thinking of using "gfx" as a package name and with classes like Font or Sprite. Now, if you wanted to use both of them, how could you since the package and class name would be the name?

Your way is cleaner, but it assumes nobody else in the world is ever going to create a package called gfx, which is a pretty weak assumption. By prepending your reversed domain name, you create a unique namespace that avoids collisions.
This fits perfectly with the "culture of sharing" that pervades Java programming, in which applications typically combine large libraries from many sources.

In Java, the convention is to name your packages (which correspond to the folder structure containing your code) with information identifying your organization (typically including a TLD and the company name) and project (which might add a few more sections).
Being more specific like this also reduces the likelihood of namespaces accidentally colliding with eachother.

It's merely an organizational technique for preventing namespace conflicts. Nothing more or less. Java package names match the underlying directory structure, so any organizational pattern at the package level will be reflected there. It's typical for teams to start their package names with their organization's name and wax specific. This is simply convention, but it's ingrained and should be followed absent a very good reason.

It's all about Namespaces. With 'Namespaces', you can create 2 classes with the same name, located in different packages/folders. This Namespace logic can also be used for creating 'Access Privileges', etc etc. Below are some links:
1) Namespace
2) Java Package
3) Java Package Naming Conventions
EDIT: Let us assume that you are creating a new project and are using 2 open source frameworks from companies/organizations - comA and comB. Also, let us assume that comA and comB have created a class in their projects with the same classname. Now, with the Java package naming conventions, we have com.comA.SomeClass and com.comB.SomeClass. You can import and use both the classes in your class, without having a conflict. This is just a simple example. There are other uses from this naming convention.

If you want to share code with everyone else, but use generic names without conflict. its considered good practice to include you domain name (backwards)
Everyone write a package called gfx.Font you wouldn't be able to use more than one version in the same application.
You might feel your code will not be shared with the world (or even should not be shared) In which case, a shorted package structure may be simpler.
If you use an IDE, it does a good job of hiding long package structures so you don't need to worry about it.

This is due to recommended packaging structure. In large projects, so many packages/libraries are used and in order not to put source files into same folder with another library, programmers put their source codes into unique folders. As websites are unique, it is a convention to use packaging structure that looks like folder structure of websites.

Java does not require anything: you can just put all your classes in the default package and surf away. But for serious projects that kind of organization is not only wise, it's mandatory. The com.mojang.ld22 part is just a convention:
com = either this or org, java/javax for official packages
mojang = second part is company name
ld22 = third part is application name

Java package naming and non .com domains

From what I understand Java packages often use a company's website as a package namespace.
For example if stackoverflow had a Java widget library it might be called com.stackoverflow.widget.
But what happens if you use an obscure TLD. Is info.example.widget acceptable?

Sure, no problem. Whatever your company's domain name and whatever its TLD is, reverse the order of its components for your Java packages.

The intent of using a domain name is that it helps ensure uniqueness using something that pretty much any organization will already have. That means that no one really needs to be 'responsible' for doling out uniques IDs for package names (or that something ugly like the GUIDs used by COM don't need to be used).
So even if your domain name is obscure, by all means use it - it's still unique.

What do you name a Java package when it isn't a part of a top level domain?

I've read the syntax conventions for naming Java packages, and I know the general rule of thumb, but what if you've just started building your application, you haven't chosen a license, and it is a personal project? It doesn't make sense to throw in "com.mycompany" or "org.myorganization" if that is not the case. Does anyone have suggestions for this?

Many Java books and online examples just use the name of the book or project, i.e., ejb3inaction.* or tutorial.*.

I usually just go with something like lastname.firstname.<other packages>. The package name should just be unique, and the combination of your last name and first name is probably unique enough (if you have a common name, throw in a middle initial or a middle name or something like that).

Perhaps org.{myname} ?
I don't think it particularly matters for personal projects. In fact I've seen commercial (in-house) projects flout this rule and simply call their packages {servicename} or similar (which I don't particularly like). The packaging rules are designed to prevent name clahes when sharing code cross-enterprise (or organisation) and consequently for personal projects you can use most anything.

Java packages are just for namespacing. Call it whatever you want! Think of something that will be useful to you later on when you want to remember what this code was supposed to do.

how about org.{projectname}? Think about some open-source projects (e.g. org.hibernate, org.springframework and org.junit) ... did they start this way because it was the name of the website, or the name of the project itself?
Besides, re-factoring is so trivial these days, just name it whatever you want.

What about name.yourname.myproject or net.sf.myproject or com.googlecode.myproject or simply myproject.
As long as you don't make your code public, it's not that important actually (and you can easily refactor it later before releasing your code if you need to). Once people start using your code, it's another story...

In the case you might also think about sharing the project (making it an open-source project), to open an project entry, in that case you can use something like 'net.sf.{project-name}.*', be careful here, that the project-name, must be the unix name, of the project (at least then you follow the rules correctly :)
SourceForge
Java Net
Google Code
Launchpad
JavaForge
Tigris.org

I generally use nl.myname.myapp for all personal projects. There is no rule against open sourcing something that uses your personal name. If you decide to make the project bigger and create a web site for it you can always rename the packages if you really want to.

java package name convention failure

I'm just coming up the learning curve for Java SE & have no problem with the usual Java convention for package names, e.g. com.example.library_name_here.package_name_here
Except.
I've been noticing a failure to abide by this in some fairly well-known packages.
JLine: jline.*
JACOB: com.jacob.* (there is no jacob.com)
JNA: com.sun.jna.* (disclaimer on the site says NOTE: Sun is not sponsoring this project, even though the package name (com.sun.jna) might imply otherwise.)
So I'm wondering, are there instances where the usual reverse-domain-name convention breaks down, and there are good ways to get around it? The only cases I can think of revolve around domain-name ownership issues (e.g. you change the project hosting/domain name, or there's already a well-known package that has "squatter's rights" to your domain, or your ownership of the domain runs out & someone else snaps it up).
edit: if I use my company's domain name, and we are bought out or have a spin-off, what should we do with package names? keep them the same or rename? (I suppose renaming is bad from the point of view that compiled classes referring to the package then lose)

It's a naming convention. There's no real requirement or even expectation that the package name maps to a domain name.

The general idea is that two organizations would not own the same domain, so using the domain name as part of the package ensures that there are no namespace clashes. This is only a recommendation however.
There is a good reason for someone to have packages in the sun namespace. If they are providing an implementation of a public API, it's often necessary to implement the classes in the API's namespace.

If you're making your way up the Java learning curve, I would worry more about making your packaging structure clear so you can easily find the class you are looking for.

Packages are used to avoid ambiguity and collisions between components built by various entities. As long as you follow the convention, and nobody illicitly uses your slice of the package namespace pie, you shouldn't need to worry about what others have used.

The only thing that matters (IMHO) is that the parts of the package name are “sorted” by importance, i.e. that you don’t end up with gui.myprog, util.myprog, main.myprog but with myprog.gui, myprog.util, and myprog.main. Whether the package name really begins with a top-level domain followed by a domain name is of no concern to me.

You can't use language keywords as parts of a package name, that's another case where the domain name convention cannot be applied - tough luck for LONG Building Technologies
But then, the convention is just that, a convention, and pretty much the only reason why it exists is that it minimizes the chance of different projects accidentally choosing the same package name. If you can't follow it, it's not really a big problem.