Lesson: Packages and Imports in Detail

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 would 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 the library classes you use and all of your classes were all grouped together, and there are library classes that have the same names as 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.

Here is a summary discussion of packages and import. Here is a video on this topic.

One more important aspect of this topic. With import you tell Java what packages or classes within packages you want to use. But where does Java actually find that code to include in your program? When a programmer creates a library of classes, (a package) the deployment step for such a project is to create a .jar file. Jar means Java Archive and is a special zip file containing the byte code for the classes packaged into the jar file. You tell your IDE what jar files are available on your computer and then when you use an import statement, Java can locate the code to import in the jar files it knows about through your IDE. Typically, one part of an SDK is all of the jar files needed to develop your programs. Your robot platform SDK contains the jar files you need and automatically configures your IDE to know about them. At some point you may wish to use a package of classes not included in the robot SDK. You would download the jar file containing the package and tell your IDE about the jar file and then you can import members from the package.