views:

1693

answers:

6

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)

A: 

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.

Bombe
Actually, what matters is that they don't collide, therefore you must have some claim on a name. Using Jline.* is unhealthy because if someone else was that stupid, your applications could not be used together.
Bill K
+8  A: 

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

sblundy
There's a pretty strong suggestion, however.
Joachim Sauer
A: 

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.

Michael Borgwardt
+3  A: 

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.

Martin OConnor
A: 

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.

James Camfield
A: 

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.

Alan Krueger