Java is one of the most popular programming languages. Java is simple, object-oriented, robust, secure and architecture-neutral.
Have you read the famous line come on your screen while installing Java,
“3 Billion Devises Run Java”
Yes, and that’s lots of code.
Giants like Google, Facebook, and Microsoft use Java for many applications. Did you ever think about how they manage to organize that much amount of code efficiently?
And the answer is simple, packages.
There are two types of packages in Java, built-in packages and the user-defined packages.
Built-in packages are the packages that are part of the Java API. It contains a large number of classes that we use commonly in our code.
If you notice the simple Java class like String, it is a part of the java.lang package. Java keeps all the classes and interfaces that are fundamental to the design of the Java programming language in this package.
User-defined packages are the packages that are created by a user for the categorization of the classes, interfaces, and sub-packages. Hence user-defined classes play an important role in organizing your code.
Below we will learn about packages in detail.
Why Packages?
The introduction part covers a little part of the answer to this question. But in this section, we will think about why there is a necessity for packages?
Can’t we keep classes, interfaces and sub-packages in one place? Yes, you can. But I am pretty sure that’s not an efficient way to organize your code.
Think about an internet banking application and imagine all the classes and interfaces related to customers, savings account, current accounts, withdrawal, deposits, security and authentication in one place. It will be a complete mess.
And that’s how the packages come into the picture. Packages help you to organize your code efficiently.
Now, think about the same application but all the classes and interfaces related to deposits in the deposit package, withdrawal-related all classes and interfaces in the withdrawal package, security-related all the classes and interfaces in the security package and so on. Now all the classes and interfaces can be access in an efficient way and you can see a big smile on the faces of the developers who are going to handle it.
Also, what if you have two classes with the same name?
You can see the example of the Date class. It comes in the java.util package as well as in the java.sql package. The Date class from the java.sql package just represent the date while the Date class from the java.sql package represents both the date and time.
Would it be possible without packages? Never. Since package creates new namespace there will be no name conflicts. We can use the same name for more than one class provided we should keep them in different packages.
Creating a Package
All Java IDEs provide the facility to create a package. We will see how to create a package in an Eclipse IDE
Create a simple Java project, if you do not know how to create a simple Java project in Eclipse IDE, I have shown it in the GIF given below.
Now you can see your project structure as shown below.
Right-click on the src folder and then select ‘New’ and then click on ‘Package’. A new screen with the title ‘New Java Package’ can be seen. Enter the name of the package you want to create in the ‘Name’ field and click the ‘Finish’ button.
There are specific conventions while naming a package. We will see that in the next section.
The following GIF shows how to create a package in eclipse.
Create a package in Eclipse IDE
Naming Conventions for packages
When it comes to naming a package, java developers follow some specific conventions.
The very first convention is, all package names are written in lowercase to avoid conflicts with the names of the classes and interfaces.
When we are creating an application for our organization, we use our organization’s internet domain in the reversed order and then our package name.
If our organization name is ‘Example’ and its internet domain name is example.com then we will create a package name like com.example.mypackage
You can also group classes and interface in a package under some other package like com.example.mypackage.mygroup
In some cases, the internet domain may contain a hyphen (-) then it will be not a valid package name. Also, it is illegal to use a digit or other special characters at the beginning of any java name so as packages.
You can use underscore to separate words in the package name or at the beginning of the package name.
Below, I have given some valid and invalid examples of the package name.
Valid package names are,
com.example.mypackage
com.example._somepackage
com.example.package_name_with_underscore
Invalid package names are,
com.exam-ple.mypackage
com.example.2ndpackage
com.example.&package
Package Members
All classes, interfaces, enums, and annotations present in the package are called package members.
When you are writing a java class in a particular package then you have to mention the full package name at the first line. It is called a package declaration.
package com.example.mypackage
public class MyClass{
...
}
We have seen the problem with classes having the same name. Since we are keeping them in different packages, we can avoid name ambiguities. We can refer them with there fully qualified names like java.sql.Date and java.util.Date.
You can import a particular member of the package or an entire package in a Java Class.
When you are importing a particular member of the package, write down its fully qualified name in the import statement.
package com.example.mypackage
import org.springframework.core.SpringVersion
public class MyClass{
.....
}
When you are importing a particular member of the class write down its fully qualified name in the import statement.
And when you want to import an entire package (i.e. all the members of the package in one go) in the class you can simply write asterisk (*) after the package name.
package com.example.mypackage
import org.springframework.core.*
public class MyClass{
.....
}
Sub-package
Package present inside another package is called as sub-package. If a developer thinks that there is a need to categorize the classes and interfaces inside a package, then he creates a sub-package.
Please note that packages are not hierarchical. When you import an entire package, you are importing all the members of that packages but not the sub-packages or groups.
import com.example.mypackage.*
The above line of code will import all the package members i.e. classes, interfaces, enums, and annotations present in that package but it will not import any package members present in any sub-packages.
You have to write a different import statement to import the package members of the sub-package, like given below.
import com.example.mypackage.mygroup.*
Packages in the Directory
When you create a package like com.example.mypackage in src folder of your project structure, it will create the com folder in the src folder and in com folder, it will create ‘example’ folder and in the ‘example’ folder, it will create ‘mypackage’ folder.
You can find all the classes and interfaces of the of com.example.mypackage package in the final ‘mypackage’ folder.
If you have written the Run.java class in the com.example.mypackage package you can find the source file at com/example/mypackage/Run.java
The following GIF shows the folder structure of your package.
The Static Import Statement
Like an entire package and package member, we can import a static member too.
Sometimes, classes contain some static members. We know their value will never change. Like PI, it has some fixed value. So we can import it for multiple uses.
In Java 5, the import statement is enhanced to import the static members. This feature is called ‘Static imports’.
The line of code given below shows how can you import static members like a package with little enhancement.
import static java.lang.Math.PI
Note: Use the static import feature very carefully. Even if it reduces some keystrokes it creates confusion in the code. Some developers think it comes at the cost of code readability.
The official ‘The Java Tutorials’ from the Oracle says,
Overusing static import can result in code that is difficult to read and maintain, because readers of the code won’t know which class defines a particular static object.
Conclusion
Packages are very much important to organize your code.
Once you created a package, please mention it at the very first line of code of the class that belongs to that particular package.
You can import an entire package by writing asterisk (*) at the end of your package name. Like com.example.mypackager.*
Source files and class files can be found in the same folder structure that is created hierarchically as per the name of your package.
And finally, a package can make a developer’s life easier.
How is your experience using packages in your Java Project? Or If you have any suggestions or queries about the blog please write it down in the comment section below.
