Programming II

This document gives a very dense summary of what we consider the most important topics of the "Programming II" course. It is meant as a starting point, explaining just the bare minimum. You will have to do some further reading – tutorials, books, articles, API documentation.

Everyone is different! We don’t want to force you to read a specific book. That’s why we leave it up to you to find documentation that suits your preferred style. Some people love reading a language specification, others learn best from examples. Some students read books cover to cover, while others hop from one Stack Overflow answer to the next.

Each chapter ends with a "Resources" section which gives helpful links. We don’t specifically recommend an official course book, but the following three might be of interest:

Sprechen Sie Java? by Hanspeter Mössenböck (5. Auflage) – The official "Programming I" course book has a certain overlap with "Programming II". We will link to the relevant sections wherever applicable.

Java Programming for Kids by Yakov Fain (free online version) – Once you get over the humiliation of reading a book for children, you will appreciate its simple and clear style.

Effective Java by Josh Bloch – A very advanced book which does not focus on Java basics, but on writing clear, correct, robust, and reusable code.

Throughout this course, you will be asked to solve exercises for each chapter. The organization of exercises is inspired by an idea called Test-Driven Development: You receive automated JUnit tests that define the desired outcome of your exercises, and are asked to implement a solution that passes these tests.

Initially, all tests are failing ("red"). You know that you are done with your exercises as soon as all tests are succeeding ("green").

For each course chapter, you receive a ZIP containing a Java project with the following main elements:

This introductory chapter will walk you through the steps needed to set up an exemplary project. At the end, you will be all set for working on the "real" exercises later.

Data structures group multiple objects into a single unit. In Java, the most basic container that can hold a fixed number of values is an array:

It seems that arrays are simple to use and need very little memory – so why ever use a different data structure?

Imagine that your program needs to read values from a file. When you write the program, you do not know how many values the file will contain, so how big should you initialize your array?

Imagine that your program needs to read some text and output all unique characters used in that text. When using an array to store the characters, how would you make sure that you do not store the same character twice? Checking the complete array every time you encounter a character will make your program very slow. And how big should you initialize your array?

Imagine that your program needs to read some text and create a histogram for all characters used in that text, i.e. it should gather statistics in the form of 'a: 33', 'b: 0', 'c: 12' etc. Of course you can use two arrays, one to keep track of the characters, and one to keep track of the counts. But how big should you initialize them? If someone was asking just for the count of the n characters, how would you look that up efficiently?

The following sections will explain List, Set, and Map in more detail.

The List interface provides a sequential data structure which grows dynamically whenever new elements are added.

The ArrayList class represents a general-purpose implementation of the List interface. Here’s how an ArrayList can be created, filled, and queried:

The angle brackets used in the List<String> declaration can be read as of element type String. The concept behind this syntax is called "generics" or "type parameterization". In our example, it guarantees that the add and get methods only allow elements of type String. Because we declare our fruit variable to be of type List<String> the compiler can tell that our ArrayList must also be of element type String, therefore we don’t have to repeat the element type but can use empty brackets <> ("diamond") instead.

As mentioned above, List is an interface (a contract), while ArrayList is a concrete implementation (a class that fulfills the contract by supporting all required methods). It is good practice to program to the interface rather than the implementation:

This assures that wherever you use your list variable, you are only using methods that are actually declared by the List interface. If you later on decide to e.g. use a LinkedList (an alternative implementation of the List interface) rather than an ArrayList, you only need to swap out the implementation in one spot.

The easiest way to iterate over all elements of a list is by using a so-called "for-each" loop:

Alternatively, all lists can also be converted to data streams, which can then be processed via The Java 8 Stream API.

You are now ready to tackle the first part of the exercises. Get yourself a coffee, import the build.gradle file contained inside prog-II-exercise-02-data-structures.zip, and get started with implementing the List101 class.

The Set interface provides a data structure that grows dynamically when new elements are added and makes sure that it never contains duplicates.

The HashSet class is the most commonly used Set implementation. The following example illustrates how a HashSet can be used:

While we can also use a "for-each" loop to iterate over all elements, the HashSet class makes no guarantees as to the order of the iteration:

This will print elements in unpredictable order:

The LinkedHashSet class represents a Set implementation which guarantees that elements are returned in the order in which they were inserted. However, this convenience comes at a certain price, i.e. a LinkedHashSet uses more memory than a traditional HashSet.

The Map interface provides a data structure which maps keys to values. A map will never contain duplicate keys (i.e. the keys behave like a set), and each key can map to at most one value.

The HashMap class is the most commonly used Map implementation. The following example illustrates how a HashMap can be used:

Each map offers three different views on its contents: it can be queried for a set of keys, a collection of all its values, or a set of its entries:

The entrySet() view is particularly helpful when iterating over the contents of a map:

This will print the following lines (in unpredictable order):

If a Map is queried for a key it does not contain, a null value will be returned. Working with null values is very error prone and should be avoided whenever possible. Java 8 offers a safe way of providing a default value for absent mappings:

The List, Set, and Map interfaces all belong to the Java Collections Framework, which provides a variety of data structures ready to be used.

In addition, the framework also offers the Collections helper class. Among its many utility methods, min and max are particularly helpful when working with numbers:

The previous sections explained how List, Set, and Map data structures all belong to a common hierarchy of collections. Some collections allow duplicate elements and others do not. Some are ordered and others unordered. But generally speaking, a collection stores a number of elements in memory.

Java 8 introduced a further abstraction, namely the Stream interface – a data source which sequentially serves elements without storing them in memory. The concept of streams is very powerful, but also quite complex. The vast number of available online tutorials is a clear indication of this fact. We will not cover streams in detail in this course, but this introductory section gives a little taste of their power.

In contrast to collections, streams do not store elements in memory but simply serve as a source of elements. Some streams provide elements by reading them from a collection, but others read them from the internet, or calculate them on the fly. Much like a water pipeline, where water only flows if the faucet is turned open, streams only serve elements as long as these elements are actually consumed.

At least three aspects of streams deserve special attention:

Let’s dive in with an example. Given a list of words, produce a list of Integer values which correspond to each word’s length:

In order to understand a sequence of instructions, it is often helpful to look at the types of intermediate results:

Just for illustration purposes – calculating the maximum length of a filtered list of words:

All collections offer a stream() method which returns a sequential stream over their elements. The following example shows how to create a stream from a List, process its elements, and convert it to a Set:

The Collectors.toSet() method internally creates a HashSet to store the final elements. That’s why the final Set does not contain elements in order. This can however be achieved by explicitly collecting elements inside a LinkedHashSet:

To round off this introductory stream section, the following example uses an infinite stream to create random dice rolls:

The Scanner class allows to read textual input:

This will print:

Each Scanner instance can be configured in how it breaks input into tokens. Various hasNextXXX() and nextXXX() methods allow to parse different value types. The following example demonstrates how to parse double values separated by a dash (-):

Multi-line input can be parsed by making use of the hasNextLine() and nextLine() methods:

Which will print:

In all examples so far we were reading input from a String variable. In reality, data is often read from a file on disk. The File class can be used to represent such a file. Note that the actual scanning logic stays exactly the same as before. However, things can go wrong when working with files, that’s why a try/catch exception handling construct is needed:

When dealing with text, String values are often created via successive concatenation, i.e. by repeatedly appending fragments. This can most elegantly be achieved via the StringBuilder class:

Which will print:

The String.format helper method allows to write out values in a specific format:

Which will print:

The PrintWriter class can be used to write text to a file:

As seen before, interacting with the File class can lead to exceptions. The try/catch clause is taking care of properly handling the error scenario. In addition, constructing the PrintWriter in the try() statement makes sure that it is properly flushed and closed once we are done working with it.

In the real world, we tend to group things into different categories, e.g. "Emma" is a person, while "Milo" is a dog, and "Basel" is a city. In Java, person, dog, and city are known as classes, while "Emma", "Milo", and "Basel" are objects.

Taking the city as an example, suppose you would like to build a catalogue of cities. Each city can be described by a name and a ZIP code. The following code shows how to model this data structure with a custom City class:

Let’s see how the City class can be used – or in Java lingo: how it can be instantiated.

The new keyword creates an instance of a class by calling the constructor which matches the number and types of the given arguments.

Our City class is composed of two fields, a name and a zipCode. The name field is of type String, which is itself a class. This is the simplest form of class re-use: We built a new class City by composing it of an existing building block, the String class.

The same approach can be used with custom classes. The following class defines a Person by re-using our own City class:

When creating a Person instance, an existing City instance is passed to the Person constructor:

Now our building blocks are complete enough to address the initial problem, the wish for a list of persons:

As seen in the previous section, the technique of composition is used to model "has a" relationships: A person has a city of residence, a city has a name. This section will explain inheritance, a technique to express an "is a" relationship.

Starting from our Person class, we can declare a new class Student which is a special kind of person:

Using the Student class is straight forward. Instances of Student offer all functionality of the base-class Person, plus additional functionality like the getSemester() accessor:

One thing to note is that the class inheritance hierarchy defines how objects can be assigned to differently typed variables. The "is a" metaphor is a good indication of whether an assignment is allowed:

While it is very convenient to inherit the properties and behavior of a base-class, it is sometimes desirable to deviate in certain aspects. The concept of overriding allows a sub-class to change the behavior of certain methods. Let’s change the Student class to return last names with a " (s)" suffix:

Now that you know how to define your own classes via composition and/or inheritance, let’s have a look at a special kind of data modeling problem for which Java provides a simple solution.

Imagine a game like Pac-Man, where a character is moving either up, right, down, or left. Somewhere in your game, you are tracking the character’s direction. What class or data-type would you choose for that purpose?

You might be tempted to use an int type and declare 4 named constants:

This is quite readable, but very error prone: The type system can’t prevent usage of a "wrong" value. Consequently, a program that compiles just fine would break at runtime:

What we would need is a type that just allows the four values UP, RIGHT, DOWN, LEFT and nothing else. Java provides a special-purpose type to represent such fixed enumerations, the enum type:

Usage of an enum is straight-forward:

Note how enums improve code readability: Just by looking at the type of the direction variable we already know something about its meaning (which was not the case with int constants). Java is a typed language. By using proper types to model our data we are taking advantage of the compiler. Errors can be caught at compile time and don’t cause bugs at runtime. By using the Direction enum, it is impossible to create a compiling program that contains a "wrong" direction value:

Each enum type automatically offers a variety of methods. Most importantly, the values() method returns all possible constants, and the name() method returns a constant’s name:

Suppose you were writing a fun little game in which unicorns played a major role. You picked up the new concepts explained in the previous sections and came up with this nice and simple class:

As you can see, someone else already wrote a Horse class – you were able to inherit most of its functionality, keeping your new Unicorn class nice an simple. Since you were done so quickly, you put all your energy and focus into listing your lovingly named unicorns in a fancy way:

This is the code that you wrote to generate the output:

Unfortunately, life is not all rainbows and unicorns. Soon you were forced to extend your game and introduce dragons. Dragons are not related to horses nor unicorns, thus you couldn’t extend any existing class. For a second you were tempted to introduce a common base-class (e.g. LivingCreature) in which you could nicely handle the name field and the getName() accessor in order not to duplicate this code. However, Unicorn already extends Horse, and multiple inheritance is not supported in Java. You decided to bite the bullet and write a Dragon class from scratch:

But wouldn’t it be nice if the list of dragon instances could be output in the same fancy style as the unicorns? Some quick copy/pasting, a bit of renaming – tada!

Hopefully you noticed how fancyUnicornNames and fancyDragonNames are almost identical. While copy/pasting might still work for two methods, it obviously doesn’t scale – soon enough you will end up with fancyKnightNames, fancyFairyNames, and fancyMonsterNames. The tiniest bug requires the same fix in 10 different places.

Taking a step back, things are actually really simple: Inside the fancyNames rendering code, you don’t really care whether you output a unicorn’s name, a dragon’s name, or a monster’s name. In other words, you don’t really care whether your fancyNames method gets a List<Unicorn>, a List<Dragon>, or even a List<Monster>. All you care about, is that whatever is in the list has a getName() method.

If you look at this simple Java assignment through the eyes of a mathematician, it is utter nonsense:

Similarly, the following Java method doesn’t have anything to do with math:

To put them in contrast, let’s look at two typical math functions and explore their common characteristics:

These functions

All three points sound really obvious in the context of mathematical functions. Yet, our Java methods often diverge from these rules in many ways.

Let’s look at our initial example again:

Ideally, a Java method declares its input and output as part of its signature. Looking at

could give the impression that our example method has one input a and one output (the return value). But this is not the case! In fact, this method

Obviously, it is not similar to a math function at all, which makes it really hard to understand.

The method has side effects: It reads values which are not declared as input parameters and writes values in addition to returning a result. It is these side effects that make the method hard to understand and cause it to deviate from the math function characteristics.

The following add method is much easier to read because it has no side effects and is thus similar to a math function:

To summarize: In functional programming, methods explicitly declare their input parameters, return one result, and do not rely on side effects.

Let’s look at another example method:

You probably have a pretty good understanding of what’s going on here, right? Even though the methods readWordsFromFile, filterByLength, and count are not shown in detail, it is still quite obvious what they are doing. This is due to the fact that all of them have good names, very explicit input parameters, return one result, and don’t rely on side effects.

Functional programming uses functions as the fundamental building blocks of a program. Just like in mathematics, where simple functions can be combined to express more complex calculations, Java methods can be combined to form a pipeline. Data flows through the method calls until the final result is returned.

Functional programming obviously makes code very readable.

Let’s go back to our initial add example:

This example may seem a little far fetched and contrived – seriously, who writes cryptic code like this?!

Actually, side effects occur very often in object-oriented programming! Accessor and mutator methods like getName() and setName(String name) only work because of side effects. Fortunately, setters and getters are so easy to implement that there’s no need to get rid of their side effects completely (though some FP purists disagree on this).

In general, side effects in non-trivial methods make implementations hard to read but also hard to write correctly. The following example will illustrate how removing side effects can prevent programming errors.

Let’s dive in with a Container class, which models a vessel with contents and a maximal capacity:

Note how add and remove both alter the container’s contents as a side effect. Moreover, both may throw an exception, another form of side effect. Specifically, add checks that the container cannot exceed its capacity, while remove assures that the requested amount is limited by the current contents.

The method transferTo uses add and remove to transfer a specific amount from this container to another container.

This is how the Container class can be used:

Interesting things happen when an impossible transfer is requested:

Of course we could invest time in fixing the transferTo implementation and making sure not to alter container states in case of errors. But it is a matter of fact that the various side effects make this implementation non-trivial. Instead of wasting time and energy, let’s instead look at how the same problem could be solved in a much more robust way – functional programming to the rescue!

For starters, we will change the add and remove methods to no longer alter the contents by side effect, but instead return a new Container instance with the changed contents:

As a next step, we want to improve the transfer scenario. Specifically, we want to make its input and output much more explicit:

In other words, we need a pair of containers as input, and also return a pair of containers. Let’s introduce a Transfer class which models a pair of containers:

The new transfer method now looks like this:

Note that it only reads state from its input parameter. Consequently, it is decoupled from the Container object, which we can make explicit by moving it to its own class:

This is how transfers can be made with our new design:

How will it behave if an invalid transfer is requested?

Phew, this was hard – but the code now works as expected! The functional programming principles of explicitly declaring input parameters and preventing side effects made the code more robust.

Often, functional programming is associated with the map/filter/reduce design pattern. We have met this pattern in The Java 8 Stream API, here it is again:

But what is so "functional" about streams? In fact, the same problem could also be solved without using streams:

This second style is known as imperative programming: Control structures like for and if determine how a sequence of statements is executed. In contrast, streams allow to express the same intentions without using control structures, solely by using functions. Extracting the lambda expressions to local variables makes this more visible:

In summary, using the functional approach of map/filter/reduce allows programmers to focus on the heart of the computation rather than on the details of loops, branches, and control flow.

Because the details of loops, branches, and control flow are no longer controlled by the programmer, code written in a functional style is very suitable for parallel execution, e.g. on a distributed cluster (Google’s MapReduce technology is the most prominent example).

Functional programming uses functions as the fundamental building blocks of a program. In Java, such functions are built by writing methods or lambda expressions which explicitly declare their input parameters and avoid any side effects. Functional programming makes programs easier to read and prevents certain types of errors.

A typical computer consists of…​

In the beginning, you were able to run a single program that had direct access to all the devices of the computer. Of course no one had the patience to wait for a single program to execute. So they wrote a special program (the operating system) that pretends to run several programs at the same time, by giving each of them in turn a little slice of time and access to the devices. No-one noticed and everyone was happy.

In order to share the screen among the programs, they came up with the idea to allocate a rectangular area of the screen to each program. The program can then draw graphical symbols into that area. They also invented a device that allows users to position a marker on the screen, and to trigger an event at that position by pressing a button on the device. It was called a mouse, and the name stuck even though its resemblance with a little rodent is not so obvious anymore.

These rectangular areas are decorated with a thin frame so that they look like windows. Some symbols are also placed on that frame that allow direct manipulation with the mouse for useful actions such as resizing, minimizing, or closing of a window. A window can be made active by the user, e.g. by clicking on it with the mouse. The window is then in focus and the operating system delivers user events (e.g. mouse clicks, finger swipes, key presses) that happen in this window to the program that is associated with it.

This concept of windows associated with apps, graphical symbols drawn into the windows, and input devices that produce events, is called a graphical user interface (GUI).

On smaller computers, especially those that are carried around a lot and used to place phone calls while other people are trying to work or have a little peace while commuting back from a hard day at work on the train, the windows are usually full screen, switching between windows is done with dedicated buttons, and interaction through directly touching the screen with the fingers. The basic concepts are the same though.

A GUI library allows a program to use the pixels inside these windows, process user events, and use the functionalities offered by the operating system.

A GUI library provides components that can be placed inside a window. Each window has a top-level container that is used to hold all the components, and to connect it with the operating system.

There are different kinds of components:

Here are some examples of typical widgets:

Here are some examples of typical containers:

All components are placed inside such container components. Containers are components themselves and can be placed inside containers.

A layout manager provides rules about how to arrange the components inside containers. Typical types of layouts are: grid, box (rows, columns), flow, absolute

Once all components are in place, the program enters an endless loop and waits for events. The operating system and the GUI components generate events if the users interact with them (e.g., mouse clicks, keyboard presses). A program can register a piece of code that gets triggered when there is an event, and that knows how to update the GUI components and the program logic.

In summary, here is how a GUI works:

There are many GUI libraries for the various programming languages, here are some prominent examples:

When programming with Java, there are two options for creating GUIs: Swing and JavaFX. Swing is the original GUI library that came bundled with Java. In recent years, a more modern GUI library was developed and since Java 8 is now also bundled with Java. Swing is not developed any further, and it is generally discouraged to start developing new applications based on Swing. In this course we will learn how to use the JavaFX GUI library.

JavaFX is part of Java 8 SE and is ready to use. The Javadoc documentation for JavaFX however is separate from the Java API documentation. See the Resources section for links.

JavaFX follows the principles outlined in the introduction section.

The top-level concept is represented by the class Stage. It is a somewhat funny name, but essentially it represents a window provided by the operating system. A Stage thus can have a title, and provides functionality to influence the decoration (frame, transparency, full screen, etc.) and behavior (resizable, always on top, etc.) of the window.

GUI components can not be directly placed onto a Stage. We need a container for that, a Scene. It determines the size of the rectangle that the window occupies on the screen, and other attributes of the graphics system (anti-aliasing, depth buffer, etc.). More importantly though, the Scene is the top of the component hierarchy, which is also called a scene graph for that reason. A Scene therefore has exactly one Parent node.

There are two types of nodes, branch nodes (where the tree branches, can contain other nodes) and leaf nodes. The following diagram shows some selected classes of the JavaFX component hierarchy.

But let’s write a simple JavaFX program now.

In order to take care of the infinite event loop, JavaFX provides a class called Application. It contains the parts of initializing the graphics system and managing the event loop. In order to use this functionality, our program can simply extend the Application class and inherit from it. Our code to generate and layout the GUI components, and to define how to react to events then goes in the method start() that we override. The Application class calls start() at the right moment, just before entering the event loop.

In order to bootstrap and run the whole thing, the main() method of our program calls launch().

Enough now, show me the code!

Great, a window with a button!

Now that we have the basic GUI infrastructure in place, let’s have a look at how to create GUI components and how to position them inside a window.

First, we add a second button.

It works, but they are on top of each other. Not very useful, we need a way to position them inside the window. The Button provides methods to define the exact size and position, relocate() and setPrefSize(). Let’s try those…​

Note that in the interest of brevity, we leave away the part about adding the Scene to the Stage from now on. It’s always the same anyway.

While this gives us full control, it seems rather cumbersome to build up a rich GUI by having to specify each and every pixel individually, and we want our GUI to adapt dynamically to changes in the window size, "responsive" so to speak.

Up to now, we used a Pane as a container for our buttons. This class does not provide any support for laying out components. There are however a number of descendants of Pane that are smarter about that. They keep track of all the components that get added to the container, and automatically assign them a position in the window based on some layout strategy. The position is dynamically adapted as new components are added, or the container’s size changes. This is called layout management.

The class StackPane is such a container component that performs layout management. Let’s see what happens if we use it instead of the vanilla Pane.

The two buttons are now positioned automatically in the center of the window. And they stay there if the size of the window changes. The layout adapts.

Wonderful, but who wants buttons that are on top of each other?

Let’s try another layout strategy, a FlowPane. In order to make our GUI a bit richer, we add two more components, two text labels.

Try resizing the window in various ways, to discover the layout strategy of the FlowPane. The components are simply placed one next to the other, like words on a line of text. When there is no more space then it wraps around.

The containers and their layout strategies can be configured in various ways. Some properties such as the horizontal and vertical gaps between components are specific to a container and have their own methods (e.g., setHgap(), setVgap()). Some properties are more generic and can be changed through the generic setStyle() method.

A FlowPane can also be put inside a StackPane, so that it is centered in the window and can be inset from the border.

It is not always easy to figure out how to change a desired property, and what properties are available in the first place. The JavaFX API documentation and your favorite search engine are your friends here.

Another very useful pair of containers are HBox and VBox. They represent simple row and column layouts, and can be nested to produce sophisticated layouts with many components. Divide and conquer!

To debug layout issues, it has proven useful to temporarily color the backgrounds of the individual containers.

Here are the relevant sections in the official tutorials:

When you use your computer’s input devices (mouse, keyboard, etc.) then all sorts of events are triggered. Which GUI component the events are delivered to by the GUI library depends on many factors, but for most practical purposes, it’s the component that currently has the focus (i.e., the mouse pointer is over it, the text field is selected, etc.).

JavaFX provides a sophisticated system of event filters and event handlers, but for standard applications, there are simple convenience methods.

Event handling code can be registered directly on a component by means of the setOnXXX() methods, where XXX is the type of event that should be handled. Examples are:

Here is a simple example of a GUI that lets users enter a text into an input field, converts it into all uppercase letters, and then displays the result. The Clear button clears the input field. Note how the input field changes background color as the mouse pointer moves over it.

Here are the relevant sections in the official tutorials:

So far we have looked at Regions. This corresponds to the leftmost branch in our sketch of the JavaFX component hierarchy.

The two other branches are Shape and Canvas. In this section we will look at Shape. We will get to Canvas in the next chapter. The main difference that we can see from looking at the component hierarchy is that Shape does not sub-class Parent. Therefore, Shape and its children can not act as containers. This is because they represent basic graphic shapes such as Line, Rectangle, Circle, or the generic Polygon.

Shapes have common properties such as the stroke (color, thickness, etc.) to draw the outline, and the pattern (color, pattern, etc.) to fill the inside.

Shapes can be added to a pane with a layout manager, just as we have seen with the other descendants of Node. More commonly though, we want to place them at exact absolute positions (e.g., to draw some data-driven graph that is made up from generic shapes). For this, the plain Pane comes in handy, since it does not perform any layout at all.

Here is a simple circle:

Try resizing the window. The circle stays put.

Now let’s make things more interactive, and use a Slider to change the radius of the circle. We need to obtain the current value of the slider each time it moves a bit to the right or to the left. So far we were able to use the setOnAction() convenience method to handle events on components. For the slider this does not work, since the movement of the slider does not simply trigger an action like a button, but changes a value.

When we have a closer look at the documentation of the Slider class, then we notice that the value of the slider is not a simple double value, but a DoubleProperty. Properties are like simple values on steroids. They are classes that wrap the simple values and provide additional functionality, in particular the possibility to observe them and get notified when the value changes.

The following code shows how to do that. Four alternative versions are shown, from the most explicit to the most concise. They all do exactly the same though. It’s just a different syntax.

Because observing a property, and then adapting another property if there is a change, is something that is done quite often, there is additional functionality to make the developer’s life easier. Properties can be directly bound to another property through the use of the bind() method. In our example, since the radius of the circle is also a property, we can directly bind it to the slider value. See below for how short this has become now:

Finally, let’s add some mouse interaction, just because we can. And because it’s fun.

Here are the relevant sections in the official tutorials:

Up to here we have covered all the branches in the sketch of the JavaFX component hierarchy, except the rightmost: the Canvas. It’s not a Parent and it’s not a Shape. What is it? The Canvas is a component that provides an empty rectangular image that you can write to. It provides a GraphicsContext that performs the rendering. You can call the methods of the GraphicsContext to define its rendering state, and to issue drawing commands.

The basic steps are thus:

The Canvas can be added to the scene graph (e.g., layout containers like the panes) like any other component that extends Node.

What is the difference to drawing with Shape as we have seen in the previous section (e.g., Circle, Rectangle, etc.)? If we use a Shape node for drawing then each Shape is an individual object that extends the Node class. With this comes a lot of functionality such as geometric transformations, bounding rectangles, styling, and event listening infrastructure. Useful, but sometime also a burden.

If we use a Canvas for drawing then there is only a single object. Drawing commands that are issued get converted to pixels on the canvas immediately. A shape drawn like this therefore looses its identity after it is drawn. It can not be addressed and modified any more. It’s just pixels. If you want to change the color of a circle then you have to change the state of the rendering engine, and draw it again.

Why would anyone want to do that?

The Canvas works like a state machine. It has rendering attributes (e.g., fill color, stroke color) that determine the current state of the rendering engine. All drawing commands are drawn using the current state. The state stays like it is until it is changed.

Here is a simple example that draws a couple of lines onto the canvas:

The documentation of the GraphicsContext class has a list of all rendering attributes. The method summary also tells you about all the available drawing commands.

Let’s try this out on a more interesting example. We want to create a number of points that are randomly distributed in the plane. When we move the mouse around in this plane, then we want to highlight all the points that are within a certain range of the mouse pointer.

We model this problem with a very simple data structure, a List<Point2D> that holds the x and y coordinates of our points.

Here is how we create the points:

The Point2D class already knows how to calculate the distance to another point. Finding all the points that are within a given range of a center point is thus very easy:

Now that the domain logic is in place, we can turn our attention to the drawing. First the points. Note how we don’t have to create any drawing objects (i.e., shapes). We simply iterate over our data model, and issue the appropriate drawing commands to get a custom drawing of the data (the points in this case). The custom drawing is very simple in this example, a filled circle, but we could replace this on the fly with something more elaborate.

Next, we overdraw the highlighting for the things that are within range of the mouse.

It turns out that we also need to draw the background, as this is not cleared automatically between drawings. Of course.

Now we are done and we can assemble everything into an application. It just redraws everything when the mouse is moved over the canvas. That’s it.

Note how the core application code reads almost like a story. This is because we were careful about isolating functionality into separate methods, with method and variable names that tell what they do.

We use static constants to avoid magic numbers and concentrate everything that can be customized in one single place.

Finally, here is the result:

Try it out! It is mesmerizing to move the mouse around and follow the spider…​

Here are the relevant sections in the official tutorials:

This section provides some help when working with JavaFX Chart components. Individual topics are inspired by the requirements of the prog-II-project.