34

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.)

Null
  • 1,950
  • 9
  • 30
  • 33
Rookie
  • 4,064
  • 6
  • 54
  • 86
  • 1
    What if I made a gfx library, and you made one - there would be a conflict for whoever needed to use both. – nos Jan 13 '12 at 15:12
  • What you describe intuitively as 'folder' has not this meaning. You can recognize they are domain names reversed: 'com.mojang' for the domain name 'mojang.com'. The purpose is exactly the same: providing a unique name. See: http://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html – mins Jun 21 '14 at 21:05
  • 6
    This is a great question, and it looks to me like no one has given a sufficient answer. All the answers below seem to say it is to prevent conflicts with other packages. Nesting classes multiple subfolders deep *DOES* help prevent conflicts, but there are much cleaner ways to achive this without *abusing* the file system this way. For example, each business could have an "org" folder e.g. `com.company.section` and then within that folder, the classes could be named `qualified.package.ClassName.class` or even `qualified/package/ClassName.class` if you want. – drwatsoncode Aug 31 '15 at 19:39

8 Answers8

8

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?

AHungerArtist
  • 9,332
  • 17
  • 73
  • 109
  • 10
    wouldnt just one subfolder fix this problem? for example `minicraft.gfx.Font` ? would make most sense to me. – Rookie Jan 13 '12 at 15:16
  • Yeah, but what you think is unique might not actually be so. In this case, yes, minicraft would probably be sufficient. The usual convention is three parts that represent the group responsible for the jar so that it would most likely not cause a conflict. It's about being safe rather than sorry. Since most IDEs can just auto import this stuff as well as go directly to classes, I really don't see why it's even a hassle. – AHungerArtist Jan 13 '12 at 15:18
  • 7
    i was thinking, why not just use one folder afterall? `com_mojang_ld22.gfx.Font` will this cause any problems? at least there wont be so many subfolders. – Rookie Jan 14 '12 at 11:47
  • 4
    Python has a different solution; you can create aliases for the packages you import. "import packageA as packageB" or "from foo import classA as classB". In case of name conflicts, rename one of them. I think I prefer this to Java's approach. – procrastinate_later Nov 13 '13 at 18:22
  • 2
    *faceplam Okay Java devs, let's think about this. If it's in a shared directory structure, how are you going to dupe it? It's a nodal structure and neither the files nor the folders are going to let you name them the same !@#$ing thing! Do you have any idea how much of a PITA it is to find CSS for the same damned web page but broken out into tiny pieces, branched out in 30 different directions, each direction a cool dozen or two directories deep? How freaking astronomical are the odds of somebody wanting the exact same NS when you hit the 9th tier much less the 20th? – Erik Reppen Sep 15 '14 at 23:17
  • 1
    @ErikReppen A lot of exaggeration there (and potentially confusion). I've never seen nine package segments, let alone 20. I'm not sure what CSS has to do with your comment. Looking at your tags, you do know Java and Javascript aren't the same, right? – AHungerArtist Sep 16 '14 at 16:05
  • @AHungerArtist I've seen code bases... hoorrible code bases. At least two that went into 9+ territory. And yes, they packed their web-app resources in at the end of those directory chains from Hell because why not? That's convenient right? Don't be surprised by JS devs who know other languages. Web UI devs of the variety that continue to learn stuff all get the server-side itch eventually. – Erik Reppen Sep 17 '14 at 00:27
  • @ErikReppen Yeah, it doesn't make sense to indict the entire convention because a select few people go to an absurd extreme. Also, you could very well have conflicts when using external dependencies if people didn't choose some distinguishing package. Otherwise, everyone would just put every class in the default package and call it a day. – AHungerArtist Sep 18 '14 at 17:28
  • Also worth noting that packages can be used for access protection, so putting them all in the same package would make that feature invalid. – AHungerArtist Sep 18 '14 at 17:36
  • 2
    @AHungerArtist I don't need access protection. I need protection from Java FUD turning every single Java experience I've ever had into a big giant pain in my ass. It's a pointless, unnecessary convention that leads to directory bloat. – Erik Reppen Sep 25 '14 at 05:26
  • 1
    @ErikReppen You sound very rational in your evaluation and statements. I hope you get past your Java PTSD. – AHungerArtist Sep 25 '14 at 16:29
  • 1
    This convention has Java stink all over it... everything has to be unnecessarily complicated and convoluted in the Java sphere for some reason... – JTW Feb 15 '19 at 21:39
  • 1
    This is the very reason why I only created ONE package name and put all classes there. So it a web app it would be like `myawesomepackage.controllers`, `myawesomepackage.models`, etc. I mean, since everyone starts their packages with com, org or other TLDs, the chances of them having that package name is virtually zero. And if it already exists, I'll just cede the name and come up with another one. Also, PHP has a different convention in which package names downloaded via Composer are written as `username\packagename`. I personally like this approach much better. – OzzyTheGiant May 09 '19 at 13:52
  • 2
    NPM uses a convention for packages that I think is really logical. Their packages can be under a name that is unique in and of itself (e.g. 'react', 'fs', 'express', etc.), but they can also be scoped by username (e.g. '@username/package'). This prevents conflicts while keeping things as simple as possible AND it only ever uses a single directory to store everything. – Christopher Bradshaw Sep 25 '20 at 21:17
  • Deno has an even more simple and even more sensible/logical way to manage potentially-synonymous dependencies: all dependencies are referenced in the code by URL. That's it. That's the end of me describing the system. All URLs are already unique, by definition. Deno caches them all locally and never forgets the local copies. Congratulations, we just used a technology that is **three decades old** for *its intended purpose*. Java's design is a crime against human thought, against reason, against the very principles of art and design. It is, in every useful sense of the word "bad", simply *bad*. – iono Jun 21 '22 at 14:44
3

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.

Ernest Friedman-Hill
  • 80,601
  • 10
  • 150
  • 186
  • 1
    Where I am working now we have multiple teams doing the same thing. So this naming convention does not prevent collisions. Additionally, why do I care about the "whole world" and not just things I am linking into my project? – Sqeaky Jul 24 '15 at 15:39
  • 1
    Well, @Sqeaky, they're just doing it wrong. If there's no central authority controlling package names at your company, then each project or team ought to use a unique package underneath the company name: that's what we do where I work. As far as why you should care about the whole world, if you're sure your code will never be shared outside of your organization, it doesn't really matter. But as the remarkable number of publicly available Java libraries attests, a lot of Java code eventually does end up getting shared. – Ernest Friedman-Hill Jul 24 '15 at 17:45
  • 1
    But why does it have to be so verbose? Why can't there just be a single directory with a prefix that guarantees that it's unique? Regardless of what prefix is being used to make a package unique, why does the directory structure have to reflect the name? Couldn't that be handled with a single value in a configuration file at the base of the project? I understand the convention has been in use for a long time, but I think it causes a lot of frustration that could be easily avoided if it were changed. – Christopher Bradshaw Sep 25 '20 at 21:31
2

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.

maerics
  • 151,642
  • 46
  • 269
  • 291
1

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.

Wayne
  • 59,728
  • 15
  • 131
  • 126
1

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.

bchetty
  • 2,231
  • 1
  • 19
  • 26
0

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.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
0

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.

Korhan
  • 232
  • 2
  • 7
-1

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
Viruzzo
  • 3,025
  • 13
  • 13
  • i think the ld22 is the competition name, minicraft should be app name, which is missing for some reason – Rookie Jan 13 '12 at 15:30
  • Of course it stands for Ludum Dare 22, he just chose to use that instead of the actual project name. There is no ambiguity anyway, and knowing Notch he probably decided the actual name halfway through the challenge. – Viruzzo Jan 13 '12 at 15:34