Essential Java Programming - Java Packages
Essential Java Programming
This training course takes you through many of the essential Java programming features. We’ll review in depth features like Language Statements, Using Strings, Subclasses, Fields and Variables, Using Arrays, Java Packages and Visibility, and much more.
- Understand key Java language statements and keywords
- Be able to develop confidently with Strings
- Be able to implement specialization using subclasses
- Work with fields and variables
- Implement Arrays to store multiple values in a single variable
- Learn how to structure your Java code using Packages and Visibility
- A basic understanding of software development
- A basic understanding of the software development life cycle
- Software Engineers interested in learning Java to develop applications
- Software Architects interested in learning Java to design applications
- Anyone interested in basic Java application development and associated tooling
- Anyone interested in understanding the basics of the Java SDK
Okay, welcome back. In this lecture, we'll introduce you to Java packages and visibility as a method to structure your code base. We'll cover items such as: using the the package keyword to define a class within a specific package, using the four levels of accessibility or visibility, using the import keyword to declare references to classes in a specific package, using the standard type naming conventions when creating packages, classes, and/or methods, visibility within the Java Modular System, and correctly executing a Java application class that is defined within a particular package. The English language is rich, but not rich enough for computers. Thus, we often have name clashes, such as the one shown above for Patent. Packages take care of isolating one name from another by providing an explicit context. Packages are a means of organizing code into large core groups. In Java, packages map directly to a directory structure. In the case of the Java Lang object class, the object class is located within the directory java/lang. Packages have two distinct sets of classes. Those of which are made public, and those of which are hidden inside the package. Hidden classes typically are support classes for the public ones, and are not meant to be used outside of the context of the package. The convention in Java is that the package names are lowercase. Class names start with an uppercase, and field or method names begin with lower case. This helps to disambiguate the dot apparatus. An example of this is Java.lang.system.out.printline where Java.lang is the package, inside package, system is a class, out is a static field within system, and printline is a method in the object referred to by out. Packages mapped to the underlying directory structure where the classes are stored.
The class path environment variable is a pointer to the root of this folder structure. The convention is that all packages will have a directory structure that maps to the reverse domain name of the company developing the code. If this scheme is adhered to, then all packages themselves will not have name clashes. The package keyword. Each class may belong to only one package. That is, only one package statement is allowed per file. The package statement must be the first statement within a source file. A package statement at the beginning of a .java file designates which package its contents belong to. Since the proper class name of a class is the full package path name followed by the class name, we would have to reference this fully qualified name in our source code. For classes whose actual class name, such as date, are unique within our source code, it becomes convenient to refer to the class by it's short name. However, since the class name could exist in other packages, we have to tell the compiler from which package we wish to obtain the class. For example, there is a date class in Java.ccore. And, in addition, there is a date class in Java.util. The import statement can be used to direct the compiler to a specific class of a specific package, or to all classes of a package. We can also have multiple input statements in our code. In the case where there would still be a conflict, say using the date class from both packages listed above, we could import one, but then use the full path name for the other, such as Java.ccore.date. Since the proper name of a class is its full name, package name plus class name, we must provide the fully qualified class name to the runtime interpreter, the jvu. This is probably the single biggest problem new developers have when trying to execute their code. Visibility modifiers allow the programmer to encapsulate or hide parts of a class or the class itself. Typically, as a programmer, you should allow the minimum level of visibility, unless there is a reason for making it more visible. This will prevent others from using the class in ways that were unintended. Java supports four levels of visibility. Public allows anyone access. Typically the class constructors and working methods are made public. Default is used when there is no explicit visibility modifier, allows only classes inside the same package to access. Protected allows access to classes inside the same package, and subclasses of the protected class. And finally, private allows access from only the class itself, typically is used for instance variables and hidden methods. Use this modifier if there is no need for anyone outside of the class to use its methods or variables. Java nine introduced the concept of modules. Until Java nine, all public types that reside on the class path were visible to all other types on that same class path.
With the introduction of the modular system, an additional layer of accessibility has been added. A module defines a logical grouping of Java packages. Each module has at least a unique name and a module descriptor which defines the meta data of this module. With the introduction of Java nine, the public keyword no longer means that a type is visible to all other classes within the runtime. A public type is only public to other types in the same module, unless the package in which the type resides is explicitly exported by the module. Within the module descriptor, all packages that are available to consumers of this module must be declared. As we will see later, a module does not have to export a public API. In this case, the module descriptor would not contain any export statements. A dependency on another module must be defined in the module-info.java file. The dependency is defined using the requires keyword and the unique name of the other module. Every module defines which other modules it requires it compile time and runtime. When a module requires a different module, we can say that the module reads the public api from the other module. When a module called airport.service requires the flight.data module, the public api defined by the flight.data module is readable by the airport.service module. Java naming conventions. It is very important to use consistent naming techniques. You can see from the examples presented here what a difference it makes. You'll also be able to read other code that adheres to the same Java convention.
Okay, before we complete this lecture, pause this video and consider the following questions to test yourself on the content that we have just reviewed.
Okay, the answers to the above questions are: One, packages provide a hierarchical namespace which helps to eliminate class name conflicts. Two, packages provide a framework for scope of access when access modifiers are used. Three, the three method and field access modifiers are public, private, protected, plus default. Four, importing a package tells the compiler to look into the package to resolve relative class name references. Five, the proper name of a class is its package name followed by its class name. And six, package names should be in all lowercase. Okay, that completes this lecture. Go ahead and close it, and we'll see you shortly in the next one.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).