Lesson: Packages and Imports

Overview: 
Explore the Java concept of class packages and using packages with the Imports statement.
Objectives: 

Understand the Java concept of class packages and using packages with the Imports statement.

Content: 

A real project, even robotics projects, can end up having many classes. You will likely need to use classes in libraries provided by FIRST or others. Finding the classes you need, controlling access to them and naming conflicts between your classes and library classes can be a problem. You may also want to organize a group of your classes into a library that can be reused with other projects or other robotics teams. Packages give us a way to group together related classes in a unique naming scheme and reference them from other classes.

Packages are intended to group related classes together and facilitate access control and prevent naming conflicts. Naming conflicts would occur if all library classes and your classes were all together and there are library classes that have the same name as one or your own classes.

You create packages with the package statement placed at the start of your class files. The package statement has your package name (more on names later) and all classes with the same package name in your project are grouped into that package. All Java programs must have a package and If you don't use a package statement, your classes are grouped into the default "unnamed" package. It is good programming practice to at least put all of the classes in a project into the same directly named package. Here is more about packages.

The Java built-in library of classes is organized into the java package and there are many sub-packages organized by function. A name.name.name format is used to create a hierarchy within packages. Here is a detailed discussion of package naming.

While a specific package name format is not required there is a detailed convention used in package names. For robotics, you might want to use a name format like this:   

org.usfirst.<fll/ftc/frc>.teamnumber.projectname

or a simpler but perfectly valid one:

teamnumber.projectname

The first example locates your project package in relation to the world. Your package would not conflict with any other package if named like this. This is a nice convention but only important if your code can be integrated into other peoples projects and you plan to do so. The second example shows a simpler package structure that works fine for projects not shared with anyone else.

Packages organize classes we want to make use of in our own classes. So how do we access these other classes? The types (another name for classes) in a package are referred to as members. To access the members of a package you can specify the fully qualified package name when using classes, fields or methods or you can use the import statement. Using fully qualified package names can get pretty tedious. The import statement makes the package name known to the compiler so that when the compiler finds a class, field or method name it does not find in your code, it uses the imported packages to look for the name. This is called resolving the reference. Here is a discussion on using the import statement. Please read this discussion as it covers important details not discussed here.

Robot programs will import some number of Java packages and some number of packages from the robotics library provided for your hardware platform. You will see examples of this when you get to the unit covering your hardware platform.

Note that you do not see any imports or package name in the CodingGround examples. CodingGround uses the default package and is doing any needed imports for you behind the scenes.

Finally, many Java compilers and IDEs want to organize your source files (.java) into directories based on the package name(s) you use. Typically a directory hierarchy is created by IDEs that matches the package hierarchy when you create a package in an IDE. So the package name suggested above might have the directory hierarchy:

c:\projectname\src\org\usfirst\frc\team4450\projectname

or

c:\projectname\src\team4450\projectname

Note that project name is repeated because the projectname right after the c:\ is not part of the package, but is part of the project directory hierarchy.

 

Navigation: