50

Why do we use reverse domain name like com.something. or org.something. structure for java packages? I understand this brings in some sort of uniqueness, but why do we need this uniqueness?

Vaishak Suresh
  • 5,735
  • 10
  • 41
  • 66
  • 3
    It's actually more in line with the convention in which left-to-right moves from the general to the specific -- think of file paths or the Dewey decimal system. You could ask, conversely, why domain names violate this convention (or why we write dates in a manner so unfriendly to sorting). – harpo Mar 19 '10 at 05:44
  • @harpo: True. Domain names and dates are better written in reverse. – Leo Jweda Mar 19 '10 at 06:17
  • The "server.domain.tld" syntax a very English-language way of expressing things (modifiers before the object - a "red ball"). Spanish, for example, has the more logical "object modifier" syntax ("bola roja"). – dlchambers Jul 02 '21 at 12:15

6 Answers6

58

About why we do it reversed: Imagine you have two important packages, an accounting package and a graphics package. If you specified these in 'straight' order:

accounting.mycompany.org
graphics.mycompany.org

Then it implies there is a major accounting package, a subsection of which is for mycompany, and a subsection of that package is called the org package which you actually use. However, you want this:

org.mycompany.accounting
org.mycompany.graphics

This makes more sense. Out of all packages from organizations (org), you look at mycompany in particular, and it has two sub-packages, the accounting and the graphics ones.

Claudiu
  • 224,032
  • 165
  • 485
  • 680
  • 10
    +1. Note that (unfortunately?) Java has no support for sub-packages, though. A subpackage is no closer to its parent (as far as visibility is concerned) than a completely unrelated package. It is of course still useful for code organization purposes. – Thilo Mar 19 '10 at 05:43
  • 2
    It only implies that org is the concrete package because you don't really pull your example through completely. What if the first part is the concrete package? Would that be impossible? -1 Strawman, right-to-left reading countries would disagree right here :P – sinni800 Sep 12 '13 at 11:24
  • 1
    @sinni800: -1 to your comment. when you write code in Java, it's written left-to-right. Further, when you have `a.b.c.d`, it means you start off with class `a`, nesting into its field `b`, nesting to that field's `c`, then nesting to that field's `d`. Analogously package organization should work the same. Also in Python packages subpackaging actually is done the way I wrote out here. So it wouldn't be impossible but it would be moronic. – Claudiu Sep 12 '13 at 15:12
  • @Claudiu But there are some portions of the language (inherited from the C-style syntax) where, while there is left-to-right reading, there is a right-to-left style (in terms of words, not characters. For example function definitions. Return type comes first, even though as a human, you wouldn't put that first.). I'm just trying to tell that there isn't an universal truth that sub pakages have to go from left to right. I didn't know about the python thing, though. – sinni800 Sep 12 '13 at 16:41
  • @sinni800: hmm well yeah everything's a matter of convention. the left->right being general->more specific is quite common though... can you name any programming languages that has packages and doesn't do it left to right? – Claudiu Sep 12 '13 at 17:07
  • @Claudiu I can not, sorry. It was just a thought and a try to pry a little of that conventional thinking loose. But Golang, for example, with external packages uses hostname/project. github.com/youruser/yourproject, for example. They split not by the portions of the host name, they rather split by the actual host name versus the project name. Golang has really taught me a lot about these things, and it's deviation from the usual C syntax: var name string, func name(parameters) returnType... – sinni800 Sep 13 '13 at 10:39
  • @sinni800: i've used Haskell which also has type declarations like you said (`foo :: Int -> Int` means `foo` has type a function that takes an int and returns an int). i see that as working either way. but ok, consider this - say you do have packages in the order you suggested, in Java. so `accounting.project` is the accounting subpart of `project`, and `reporting.project` is the reporting subpart of `project`. now you have a class in each, `accounting.project.AccountManager` and `reporting.project.ReportGenerator`... doesn't that look wrong? It's mixing two conventions in one – Claudiu Sep 13 '13 at 12:38
  • @sinni800: or if you have subclasses, `account.project.AccountManager.FooBit` vs. `reporting.project.ReportGenerator.ReportingSubsystem`. now the left half of the name is specific->generic, but the right half is generic->specific. I could see it working the way you said if the syntax for accessing fields also worked by prepending stuff on the left side, but it doesn't work that way in Java. – Claudiu Sep 13 '13 at 12:39
  • @Claudiu Okay, what if we try to change that around a little bit... account.project::AccountManager (this still looks horrible, but the distinction is here now)... Everything might have a solution, but the one you suggested really is not. I never wanted to suggest something like that, to be honest. – sinni800 Sep 13 '13 at 15:48
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/37347/discussion-between-claudiu-and-sinni800) – Claudiu Sep 13 '13 at 15:49
  • It makes more sense, unless you've used the internet before. In which case it's needlessly pedantic. – Erik Aronesty Sep 06 '18 at 17:54
39

Globally unique package names avoid naming collisions between libraries from different sources. Rather than creating a new central database of global names, the domain name registry is used. From the JLS:

The suggested convention for generating unique package names is merely a way to piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for package names.

Laurence Gonsalves
  • 137,896
  • 35
  • 246
  • 299
4

As you say, reverse domain names as base package name ensures uniqueness. Suppose two companies with DN example.com and example.org both define the class Employee in their framework. Now if you are using both frameworks you will not be able pinpoint which Employee you want to use in your code, but if they are defined in packages com.example and org.example respectively you can tell the compiler/JVM specifically which class you are referring to. If unique packages are not defined you will get compilation errors or runtime errors, e.g. if you are using the com employee class, but the org employee class gets loaded first from the classpath you will get a runtime error, since the two employee classes may not have same structure.

inetphantom
  • 2,498
  • 4
  • 38
  • 61
saugata
  • 2,823
  • 1
  • 27
  • 39
3

The uniqueness is needed for Class Loading.

It helps by avoiding naming collisions. If there are classes with same package name and class name, Collision will occur while trying to load the classes.

This generally happens if there are multiple libraries(jar) that contain classes with same names.

Also see this.

Padmarag
  • 7,067
  • 1
  • 25
  • 29
  • What sort of loading are you talking about? and how does naming it uniquely prevent a possible collision? I assume that whatever conflict occurs during loading, occurs if the class name is also same. – Vaishak Suresh Mar 19 '10 at 05:38
  • @Vaishak: That assumption is false. The unique name identifying the class is the package + the class name. If you're in the same package or if you have specifically imported a package or fully qualified class name you can use the name only. Much like with dialing a phone, you normally don't need to specify area code if you're in the same one already but the full phone number that you hand out would still include the area code. – Fredrik Mar 19 '10 at 05:43
  • @Fredrik My assumption was in line with your explanation :) That is why I said conflict occust if the class name is *also* same. But my question has been answered now. Thanks! – Vaishak Suresh Mar 19 '10 at 05:58
0

You need the uniqueness if you might need to integrate your code with third party software, or provide it to someone else for integration. If you don't follow the rules, you increase the risk that at some point you will have a class naming collision, and that you will need to rename lots of your classes to address it. Or worse still, that your customers will have to do the code renaming.

This also applies when code is produces as part of different projects in an organization.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

As you said, it brings uniqueness, something that is needed especially when working with third party code. For example, consider that you are using a library I've made. I've used the package "foo" and have a class named Bar there. Now if you are also using the package name "foo" AND you have a class named Bar, this would mean that your implementation would override my Bar implementation, making my implementation inaccessible. On the other hand, if my package were "com.mydomain.foo" and I'd had by Bar class there, then you can freely use the name Bar in one of your classes and both classes could still be uniquely identified and used separately.

Why use the reverse domain name as the package name? I guess that is just a convention to make sure that everybody uses a unique namespace, as you shouldn't use someone else's domain in your package name.

KCL
  • 6,733
  • 10
  • 37
  • 43