Introduction to Packages

Let's talk briefly about Java packages. Now packages are a very important concept in Java, and we can talk a great deal more about them later. We have a whole module dedicated to them. I want to look at just a couple of simple things about packages right now to get us started. Now, if we look at our source code, all the source code we've written up until now has just kind of our class definitions, and that's kind of by itself. But if you look at most Java source code out there, you'll see that at the top of the source code files is the word package, followed by some name, and what this does when we add this package concept is it provides organization within a Java program. Now, again, there're a lot of aspects of that, but I want to look at just kind of two basic aspects of it to get us started. One is that these package names follow a standard naming convention, and they affect our source code file structure. Now in terms of the naming convention, one very simple rule is that package names are all lowercase. That's just a convention. The compiler would allow it not to be a lowercase, but that is the convention that package names are all lowercase, and one of the things that we're trying to do with package names is create a sense of uniqueness. So, one aspect of uniqueness is on a global scale, throughout the entire world. So, in order to assure package name uniqueness on a global scale, what we generally do is use the reversed domain name. So, for an example of that, Pluralsight owns pluralsight.com. There's an authority out there that makes sure that no one else buys the name pluralsight.com. So, what we do is that we start off our package names using a domain name. So, any package created by Pluralsight would use the name co. Pluralsight. Again, it's reversed. So, the top level of its com and then Pluralsight, so that now assures that if everything we do at Pluralsight starts with that naming structure, no one else will name a package like that. And, again, there's nothing that enforces this rule. It's just a convention that we all follow to keep things from colliding with one another. And then what we want to do is that we add further qualifiers beyond that to assure uniqueness within an organization in the case of a company or some group. If we're creating packages that belong to co. Pluralsight, each of our individual packages would have another part to it that just identifies some project. So, in this case, it's my project. And that's kind of the simplest way to assure uniqueness, that each project can have its own kind of last node part to that or last part of the package name, and it stays unique. As organizations get larger, you may have to get a little bit more sophisticated about your package names because if you have multiple development groups within an organization, if you only have these three parts, the top level, co. Pluralsight, and then that last part, all the groups would have to coordinate to make sure they didn't collide with one another. So, what often happens is that as you get into larger organizations, you'll add another standardized part to it. So maybe you have co. Pluralsight, but if Pluralsight had their own development group for the accounting department, you might agree that, well, everything created by the development group in the accounting department is com.pluralsight.accounting. And then say if there was another group instead of Pluralsight and say that was the group that took care of course management that was their own development group, they would then agree that, well, all the packages they create are com.pluralsight.coursemgmt. And then there's no concern about colliding because then when they name their individual projects, if they named them both my project, there is no package name collision because the earlier part that was qualified by their group created the uniqueness. And, again, these are all conventions. There's nothing enforcing all this, but these are rules that we follow to make sure our package names don't collide. Now as we put members into a package, those members, of course, become part of that package, and that package becomes part of the members name. So, if we just build a class called Main, well, the name of that class is just Main. But now once we put that class inside of a package, the package name becomes part of the overall class name. So, the class is no longer known as just Main. The class is now known as com.pluralsight.myproject. Main, and that becomes again, a unique name. And because we all follow these naming conventions, we now know that anyone else in the world can create a class called Main, but because it's qualified by a package that follows a convention, the class name itself is actually unique when qualified fully by the package. Now one of the most significant things that affects us about packages at this early point in talking about Java is that it turns out these package names affect the source file structure. Now what's interesting is that Java itself requires no correlation between your package names and your source code file structure. In other words, it doesn't care how the packages are named, it doesn't force you to position or structure your source files in any given way. That's Java itself. The thing is most IDEs do require your subfolder structure to match up to the parts of the package name. So the thing is that even though Java doesn't require it, we kind of can almost ignore that because in practice, most tools that you work with are going to require that your source file structure match up to your package names. So, what does that look like? Well, if we build a class, as we have earlier, where we didn't put it inside of a package, well, the way the IDE expects that to go is that you've got your source code folder, and then your Java class file just goes right inside that same source code folder. That's exactly what it expects. But if we now have a package definition in our source code file, the presence of that package name now enforces a structural rule on the way the IDE expects the source code to be laid out. And, basically, it's that each of the parts of that package need to be there‑‑‑I should say each of the parts of that package name need to be in their own subfolder. So, under src, the IDE expects a com subfolder to match the first part of the package name. Then under that it expects a Pluralsight subfolder, and then an example subfolder, and then, finally, our Main.java is expected to be inside of there. So, as you have different package names, this hierarchy is going to have to match up to all those. Again, this is true in IntelliJ. It's true in NetBeans. It's true in most IDEs.