1. Packages
Ordinary Java programs involve an enormous number of classes. How many? Thousands, tens of thousands. And if you also account for the fact that the program uses various libraries containing classes written by other programmers, then the number of classes can easily be measured in the millions!
It would be all but impossible to come up with unique names for all of these millions, or even just thousands, of classes.
Of course, we can imagine names like A123 and B345, but if we are talking about choosing a good class name, one that makes it easier to understand the class (like String for strings, for example), then even generating a thousand unique names is a lot of work.
That's why in Java it is customary to group classes into packages using the package keyword.
Java classes and their packages are very similar to files and folders on a computer.
For example, if you need to store 10 documents on your computer, you would probably just keep them in one folder. But what if you have thousands of documents (for example, a repository of all a company's documents)?
With thousands of documents to be stored, one solution is to create multiple levels of folders with good descriptive names. And then in a folder at the very last level, store the documents that relate to that particular folder. Good descriptive names for the documents don't hurt either.
In fact, we do all of this for classes in Java.
The files containing the classes are stored in different directories (folders), and the full name of the class's folder with all its subfolders is the name of the package. Example:
| Path to the file | Package name | Class name |
|---|---|---|
|
|
|
|
|
|
|
|
|
Unlike folder names, package names use a dot as a delimiter. In other words, the folder \com\codegym\tasks\ corresponds to the com.codegym.tasks package.
2. src folder
In Java, it is customary to store all the classes for a program in a single folder (and subfolders). This folder is usually called src (short for source).
This folder is called the project root (or source root), and all package paths are relative to it. Examples:
| Folders | Package name |
|---|---|
|
|
|
|
In this situation, programmers say something like "we have a project named my, which is located in the c:\projects\data folder" or "we have a project named project, which is located in the d:\files\git\data folder"
It is best to always put classes in packages and not directly in the root folder (src. If you have just a few classes, this doesn't present a problem. But when there are many classes, it is very easy to get confused. So, always create your classes only in packages.
In Java, it is customary to give meaningful names to classes and packages. Many companies release their own libraries (a set of classes) and, to avoid confusion, they incorporate the name of the company/website/project into the name of the package:
| Package name | Company/project name |
|---|---|
|
Apache project |
|
Oracle company |
|
Oracle company, Java project |
|
IBM company, WebSphere project |
|
JBoss project |
3. File contents
According to the Java language standard, information about a class name and the name of its package must be included in the file with the code. The general form is shown below:
package package-name;
public class ClassName
{
}The package name must match the folder name, and the file name must match the public class name.
If you have a ...\src\com\project\Service.java file, then it should contain this:
package com.project;
public class Service
{
}4. Importing classes
The class name and package name form what is called the fully qualified name of the class.
Examples:
| Fully qualified name | Package name | Class name |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
none |
|
The good news:
The fully qualified class name is always unique within a project. After all, you can't create two files with the same name in a single folder.
The bad news:
Fully qualified class names are usually either long or very long. And writing out a long name (for example java.util.ArrayList) every time in code is super inconvenient.
That's why Java added the ability to import classes.
You can use a class's short name in your code, but you must first let the compiler know which fully qualified class name corresponds to the short name. What if you now multiple classes with the same name in your project? Or you originally has one, but then 15 more were added...
To use a short class name in your code, you need to add the following construct:
import fully-qualified-class-name;This declaration must be added at the very beginning of the class, right after the package declaration.
Example:
package com.codegym.tasks.task01;
import java.util.Scanner;
import com.test.helper.special.ArrayList;
public class Solution
{
public static void main(String[] args)
{
Scanner console = new Scanner(System.in);
ArrayList list = new ArrayList();
}
}We imported two classes (java.util.Scanner and com.test.helper.special.ArrayList), so we can use their short names in our code. And the compiler will know which classes to use.
And here's what the same code would look like if we hadn't used import:
package com.codegym.tasks.task01;
public class Solution
{
public static void main(String[] args)
{
java.util.Scanner console = new java.util.Scanner(System.in);
com.test.helper.special.ArrayList list = new com.test.helper.special.ArrayList();
}
}By the way, if your project has two classes named Scanner, you will not be able to import both of them into the same file: you will have to use the long name for one of them.
Let's say you have a Jen on your team. There are no communication problems, since everyone knows who she is. But if there were three Jens, then fully qualified names would have to be used to distinguish them.
By the way, if you're too lazy to add lots of import statements to your class, you can use its lazy version: instead of a specific class name, put an asterisk:
import package-name.*;That will allow you to use the short names of all the classes in the package.
All classes in the java.lang package are imported automatically, so you don't need to write an import statement for them. You're sure to already know one of these classes: java.lang.String. Yes, that's right. This is the String class that we have used for working with strings.
GO TO FULL VERSION