Lesson 10: Packages

By this point, you have a solid grasp of JavaFX Script programming language basics. However, the location of source files is likely to be a little disorganized (by now you probably have a single directory filled with lots of unrelated examples). We can improve our overall organization by placing our code into packages.

Packages make it possible to group your code according to functionality. They also give your classes a unique namespace. We'll explore this below with a step-by-step example that places the Address class into a specific package.

Before we modify any code, we must first choose a name for the package that we'll be creating. Since our Address class is intended to be used in a (hypothetical) addressbook application, we will use "addressbook" as the package name.

Next, we must create an addressbook directory on the filesystem itself. This directory will contain the .fx source files for any classes that we designate as belonging to the addressbook package. Feel free to create this directory anywhere you want; we will use /home/demo/addressbook in this example, but the scripts must be in a directory matching the name of the package, in this case addressbook.

Now, go to the addressbook directory and create the Address.fx source file. Paste in the following source code. The first line provides a package declaration, which states that this class belongs to the addressbook package:

package addressbook;

class Address {
     var street: String;
     var city: String;
     var state: String;
     var zip: String;
}

Note that when a package declaration is present, it must appear by itself as the first line of code in the source file. Only one package declaration per source file is allowed.

Next, we must add the public keyword to the Address class and its variables:

package addressbook;

public class Address {
     public var street: String;
     public var city: String;
     public var state: String;
     public var zip: String;
}

This keyword is one of five available access modifiers. We'll explore the access modifiers in the next lesson. For now, just know that public makes this code accessible to other classes and scripts.

While still in the addressbook directory, compile this source as usual with the javafxc Address.fx command. (In larger software projects, there are more sophisticated ways to build code from multiple packages, but compiling the source in this directory will work fine for this example.) After compilation, this directory will contain the resulting .class files.

We are now ready to test the modified Address class. But first we will change back to the parent directory /home/demo. Here we will create a simple script, packagetest.fx, that tests the use of the addressbook package.

There are a couple of approaches that we can take to access this class:

// Approach #1

addressbook.Address {
     street: "1 Main Street";
     city: "Santa Clara";
     state: "CA";
     zip: "95050";
}

Approach #1 creates an object using the fully qualified class name (which is now addressbook.Address). Compared to other methods, this approach will probably feel too cumbersome (especially in large scripts), but still, you should know that it exists.

// Approach #2
import addressbook.Address;

Address {
     street: "1 Main Street";
     city: "Santa Clara";
     state: "CA";
     zip: "95050";
}

Approach #2 uses the import keyword, which allows the short name (Address) to now be used anywhere within the script. This approach is recommended for larger programs because it is self-documenting. At a glance, you can tell what package each class belongs to.

// Approach #3

import addressbook.*;

Address {
     street: "1 Main Street";
     city: "Santa Clara";
     state: "CA";
     zip: "95050";
}

Approach #3 uses the wildcard "*" to import all of the public classes defined in the addressbook package. In this example there's not much advantage to doing this, but if a package contains a large number of classes, you can use this technique to import them all at once. Some programmers find this convenient; the downside is that with this approach, it becomes more difficult to tell what package a given class lives in, especially when multiple packages are involved.