Writing a class or two doesn’t seem to create that big of a problem, and for simple projects it’s not. However, this isn’t effective for large projects with dozens, if not hundreds, of Classes.
That’s where packages come into play.
A Java package is a way to both logically and physically organize your Java code. You can place files into folders (physically organizing them) and create multiple packages based upon what they logically do.
So for example you might see something like com -> access2learn -> tutorials. Each -> would be a new sub-folder. Normally you work with a domain, like you would a web domain, the company name, and then a project name. You can even have more sub-folders for additional pieces.
For example you might see com -> access2learn -> tutorials -> javaClasses.
Notice that it reads backwards of a web domain. This is because with each level down, you are getting more and more specific.
There are two types of packages, built in packages and user defined packages. Some of the built in packages include:
- java.lang: Contains language support classes(e.g classed which defines primitive data types, math operations). This package is automatically imported.
- java.io: Contains classed for supporting input / output operations.
- java.util: Contains utility classes which implement data structures like Linked List, Dictionary and support ; for Date / Time operations.
- java.applet: Contains classes for creating Applets.
- java.awt: Contain classes for implementing the components for graphical user interfaces (like button , ;menus etc).
- java.net: Contain classes for supporting networking operations.
User defined packages, don’t mean just you as a user/developer. It could be other companies or developers. The logical organization of it lets you know who developed the package, especially if it was someone else, and helps minimize issues with having classes with the same name.
When you import another package, it must me in your system CLASSPATH as defined by your OS. Then in the code it would look something like:
import java.sql.*; // import every class in the package java.util
import java.util.Date; // import a specific class in a package This previous example is shown for two reasons. One, we can use the * (wildcard star) to import all of the classes in a package. And two, we can import a single class in a package.
But it’s more important than that. Both java.sql and java.util have a Date class. If we don’t specify which one we are going to use, we will generate an error when we compile to byte code since the system won’t necessarily know which one is which.
To avoid any confusion, we can use the following method to make sure we grab the right class.
java.util.Date deadLine = new java.util.Date();
java.sql.Date today = new java.sql.Date();Notice when we declare the object, we put the package name in front of it, that way there is no confusion for the computer compiler.
If we want to build our own classes in a package, we need to first make sure the file exists in the right set of folders. Then inside the java file, we’ll add a package line of code to ensure that it is included when the package is built.
package myPackage; This would be above/outside the class definition. just like the import commands would be.
When you define a package, you automatically have access to those other classes, and don’t have to import them.
A couple of final thoughts, especially for those without a package defined, which I’m sure you are wondering about.
- Every class is part of a package. If no package is specified, the classes in the file goes into a special unnamed package (the same unnamed package for all files).
- All classes/interfaces, in a file (we’ve not looked at subclasses yet, but when we do, they are what we reference here), they are included in the same package.
- Multiple files can specify the same package name.
- If package name is specified, the file must be in a sub-directory called name (i.e., the directory name must match the package name).
Intro to Java – Packages was originally found on Access 2 Learn
