Java Keywords (Part XIII): Import Keyword and the Concept of Java Packages

We are up to 36 keywords covered in previous articles! That's 75% keywords covered. We have only 12 keywords to cover and I will be covering 2 of those in this article. I am so excited about getting to nearly the end of the series. As I mentioned before, knowing the Java keywords and being able to explain their usage correctly, is something that you will most likely need in an entry level Java programmer job interview. If this ever helps one of you, I would love to hear from you! This article will illustrate the use of the keywords import and package. This is going to be a very short article. I promise. I suggest you start with Java Keywords (Part I) before proceeding further, if you have not read any of the previous articles in the Java Keyword series. Also, go back and read the one about Data Types. All of these articles are from September 2018. That should help you find them quickly. You can also use the "search" option at the top of this page. The series was written with natural progression in mind. Therefore, some of the keywords already covered may be used in code examples illustrated here.

Java keyword list

abstract continue for new switch
assert default goto* package synchronized
boolean do if private this
break double implements protected throw
byte else import public throws
case enum instanceof return transient
catch extends int short try
char final interface static void
class finally long strictfp volatile
const* float native super while
Keyword marked with an asterisk (*) are keywords that, although valid, are not used by programmers.

Packages

The purpose of the keyword package, is to define the namespace for the classes contained in it.

The simplest way to think of a package is as a folder; mainly because it is indeed a folder. We use folders primarily to keep things organized in a logical way. Most computer Operating Systems offer a series of folders out of the box, to help us stayed organized: Photos, Videos, Music, Documents, Desktop. When we want to store photos, it makes sense to store them in the "Photos" folder. We can also create our own subfolders to further organize the contents of a folder. For instance, you may want to store last year's vacation photos in "Vacation 2019" insde the Photos folder. Likewise, we can use packages and sub-packages to compartmentalize our classes in groups that make some logical sense. This partitioning provides a namespace for our classes. Namespaces help with avoiding collisions with other classes that may have the same name; just like you cannot have two files with the same name in the same folder. So, if you need to tell the operating system that you need a certain file, providing the full path and name of the file guarantees that you will get precisely the file you need. In Java, the combination of the package (path) and class name is known as the Canonical Name. For more information on packages, please visit my article on this very topic.

Package view in Eclipse
Going back to the original point, defining a namespace means that classes inside a package have a specific definition that is different than classes with similar name elsewhere. Suppose you have two table classes: package1.Table and package2.Table. Even if these classes do the exact same work, you have to assume they are different from one another for the simple fact that they are defined in different packages. Therefore, instances of one "Table" class are not necessarily compatible with instances of the other "Table" class. More about this "conflict" on the Importing Classes section.

Another benefit of packages, is that serves as a way to encapsulate features of a program or library. For example, there might be classes inside a package that may not be suitable for direct access by external entities. Thefore, declaring these classes with default access modification (see Part I of this series for a refresher) "hides" these classes from the outside. This information hiding helps in keeping your API simpler, by only making visible those classes suitable for external access.

Importing classes

Importing classes mean that you want to bring in (use) functionality that exist in another namespace without having to use the canonical name of a class (or fully qualified name). Obviously, if two classes share the same name that are used in a single class file, you have no choice but to resolve at least one with its fully qualified name. In the previous example of "Table" classes in two different packages: 

package package3;

import package1.Table;

public class MyApp {
	
	public static void main (String[] args) {
		Table t1 = new Table();
		package2.Table t2 = new package2.Table();
	}
}

When you import, it is considered a good practice to import only the classes you need from any given package. However, Java supports the use of the asterisk symbol (*) to import all classes inside the named package. It will not import classes in subpackages. In the example above, you cannot import two classes with the same name, even if they are defined in different packages. On the surface, this might not make sense to you. But, if you really think about it, this is necessary because you won't be able to differentiate in the body of a class one type of object from the other. Consider this example: 

package package3;

import package1.Table;
import package2.Table; // This import will cause a compiling error

public class MyApp {
	
	public static void main (String[] args) {
		Table t1 = new Table();
		Table t2 = new Table();
	}
}
How will the program know which "Table" class you want to use for objects t1 and t2? If you think you can get around this issue by using import all wildcard on one of the import statements, the code will assume that you want to use the class type that is explicitly declared. If you use the wildcard on both import statements, both t1 and t2 declarations will result in a compiling error until one is explicitly imported and the other one declared with its fully qualified name, just like in the orgininal code snippet.

You may be asking yourself "when do I need to "import"? You need to import classes when they reside outside the declaring class (namespace) package.

Notice on the image above how the IDE is indicating an error with the use of the "MyClass" class. This is because "MyClass" and "MyOtherClass" exist in two different packages. Therefore, if not using "MyOtherClass" fully qualified (canonical) name, I must include an import statement to use it. 

/*
 * Programming Corner
 * Professor Fontanez
 * www.professorfontanez.com
 * May 9, 2020: 10:58:09 AM
 */
package package1.subpackage;

import package1.*; // import all classes in package1 (assume MyClass resides in that package)

public class MyOtherClass {
 
 public MyClass myAttrib;
}
An exception to the rule mentioned above, classes from the Java library that reside inside the java.lang package do not need to be imported. The JVM import those classes for you. These classes are essential to the Java language, and by extension, to all programs; being the most noticeable the Object and String classes.

Comments

Post a Comment

Popular posts from this blog

Combining State and Singleton Patterns to Create a State-Machine

Image
In my previous two posts, I discussed real-world applications for the Singleton and State design patterns. In this article, I am going to illustrate how to combine both of these patterns to create a simple wizard. Simple State Design Pattern Implementation In a typical implementation of the design pattern, State is either an interface or abstract class, with each state of the state machine being Singleton classes. My example is going to be slightly different. I will implement the state machine using a state interface and Java enums to implement the Singleton. Using an enum is the recommended way to implement a Singleton in Java. First, let's come up with a simple state interface State.java public interface State { void goNext(Context input); void goPrevious(Context input); } Now that we have an interface defined, we can derive as many states as we need. For this example, three states should be sufficient to demonstrate the wizard's functionality. Jav
Read more

The Beauty of the Null Object Pattern

Image
Before we start... Let me start by saying this: NEVER dismiss an idea without giving it any consideration. That was the mistake I made when I first encountered an article about this design pattern many years ago. I was thrown off by the name and without even attempting to find out what this design pattern was all about, I moved on to other things. That was a huge mistake and I am not afraid to admit it. I urge you not to make that mistake. And if you have already, never make that mistake again. Trust me, you will thank me later. For now, let me tell you my story and attempt to explain when to use it along with a simple example on how to implement this pattern. The Null Object Pattern By definition, the main purpose of this pattern is to have an Object-Oriented alternative to the absence of objects by creating objects that display "do nothing" behavior. That sounds like a mouthful. In simplest terms, it is meant to provide a mechanism to replace null references w
Read more

Exception Handling: File CRUD Operations Example

Image
Introduction to Exception Handling This is a supplement to my previous blog Creating Custom Exception Classes in Java . I recommend you read that one first and then read this one. Java provides many Exception (and Error) Handling classes. Both of these categories implement the Throwable interface. Although it is not imperative that you develop your own custom exception classes, it is often a good idea to do so; particularly when dealing with large systems. The main reason to create custom exception classes is to quickly identify which custom class is being affected or causing these custom exceptions. For example, referencing a null object and trying to use it will result in a NullPointerException . However, in your code, there could be literally hundreds or even thousands of statements which could result in such exception. Designing your Custom Exception Class Suppose that you are designing a class that will serve as a message receiver. For simplicity,
Read more