10. Packages

Except for very small programs, most Groovy and Java-based programs are made up of packages of code:

  • The package keyword is used to designate that a class is part of a package and we’ll cover this more fully in the Organising your code chapter.
  • The import keyword is used to import classes from other packages into a program.

Consider the sample code below:

Using imports
package test

import java.time.Year

println Year.now()

I’ve indicated that this code:

  • Is part of a package named test
  • Needs to use the Year class defined in the java.time package

This notion of packaging allows for thousands of developers to create classes and packages without clashing. If another developer creates a Year class but puts it into a package with a name other than java.time then all will be well. Oh, and you’d never start your own package name with java. - that really won’t work out well for you1.

Before you write any new code you should always check out these resources in the order I’ve given below:

  1. The Groovy API (GAPI)
  2. The Groovy extensions to the JDK (GDK)
  3. The standard Java classes (JDK)

Using the order I’ve provided above lets you look at the libraries providing the Groovy approach first (the GAPI and GDK) then looking at the Java standard library (JDK).

For the rest of this chapter I’ll focus on import as that will help us in the early set of tutorials.

Using import

You can import other classes in a variety of manners - let’s take a look.

Basic Imports

The basic form of imports are the most commonly seen and you should get accustomed to them pretty quickly.

import java.time.Year
This will import the Year class from the java.time package
import java.time.*
This is a star (wildcard) import
This will import all classes in the java.time package

Static imports

Static imports can help your code look a little cleaner as they give you an easy way to refer to useful constants and functions (methods) declared in other code packages2.

import static java.lang.Math.PI
This is a static import
This lets you import static items from another class
In this example I’ve imported the PI constant from the java.lang.Math class and can now use it as if it was just part of my code: println PI
import static java.lang.Math.PI as pi
This is a static import with aliasing
This is the same as the previous import but I can use the as keyword to rename the item being imported - I’ve decided to use PI but refer to it using the lowercase form (pi)
import static java.util.UUID.randomUUID as generateId
This is also a static import with aliasing but I’ve imported the randomUUID static method and given in the alias generateId
I can now call println generateId() in my program
import static java.lang.Math.*
This is a static star import and will import all static elements described in Math and let me refer to them directly in my program.

I’ve thrown the term static around a lot here - don’t worry too much about this for now as we’ll really only need basic imports for now. The notion of static will be covered when we get to object-oriented Groovy.

Built in Libraries

The following libraries are imported into Groovy by default - you don’t need to do anything to start using them:

  • java.io.*
  • java.lang.*
  • java.math.BigDecimal
  • java.math.BigInteger
  • java.net.*
  • java.util.*
  • groovy.lang.*
  • groovy.util.*

Groovy is able to make use of classes within these packages without explicitly importing them. You can still declare them with import and you’ll notice various development environments (IDEs) will do this regardless of Groovy’s default - either way it’ll be groovy.

Useful third-party libraries

There is an extensive body of existing Java libraries available to the Groovy developer and it’s best to do some investigating before you write your own code - re-using well-supported libraries is a real time saver - here’s a couple to take a look at:

  1. Apache Commons
  2. Google Guava

In the olden days (in Java-time) you’d often have to download the third-party library you wanted, download any other libraries it depended on, store them in the correct place (called a Classpath) and then you could start using it. Time went by and systems such as Apache Maven came along to make it easier to grab a copy of your dependencies. This then lead to The (Maven) Central Repository and made it even easier to grab the libraries you needed.

  1. There’s actually a package naming convention that is very easy to follow.
  2. We’ll describe how these are written in the Class Methods and Variables chapter.