Documentation and Tutorials

What is Android? — Quick start on architecture .

Application Fundamentals — Terminology and Components

Hello, World tutorial — very basic tutorial

Notepad tutorial — nice tutorial with “problems” to work though, as well as a clear goal.  Demonstrates different parts of an app’s lifecycle.

Development Set-Up

You’ll have to go through several steps to get a fully working development environment.  Start with the Android SDK.  Download to somewhere reasonable, then cd into {android’s home}/tools and run android.  This brings up the SDK/AVD manager, which can pull down samples, documentation, and runtime environments for the different Android versions.  It also is where you set up and launch the device emulators.

Get the Eclipse plug-in for Android next, if you like that sort of thing.  Be sure to configure the SDK location in your preferences.  Note that you can launch the SDK/AVD manager right out of Eclipse, if you like.  If you don’t want to use the plug in, be sure to check the documentation for the command-line tools, which can do many (if not all) of the Eclipse plugin’s functions.

Another way of putting it is that I’m ashamed of the state of our industry, in these cases.  It may be inertia, or the teams I’m on, or anything, but I still have to fight it, understand it.  These things are what we should be laughing about, when talking about the bad old days.

I have some thing swirling in my head… part of this may be the continuation of the Java Build Systems posts I had earlier, and more.  Next two entries, I think: Java and ORM, Java and the Web.

This is my current gold-standard set of podcasts:

Podcast / RSS Link	Category	Average Length	Description
Major Nelson Radio	Gaming	1:15 - 2:00	Gaming podcast, focussed almost exclusively on the Xbox 360. Interviews and news.
IGN Games Podcasts	Gaming	0:40 - 1:15	I listen to the following podcasts from this RSS: Game Scoop (all around gaming news) Three Red Lights (ostensibly 360, often silly) Nintendo Voice Chat (Wii / DS) Command Prompt (PC Gaming)
IGN Entertainment Podcasts	Television / Movies / Technology	0:40 - 1:00	I only currently listen to Channel Surfing, but occasionally there are other interesting podcasts
Bungie Podcast	Gaming	1:30 - 2:00	Bungie studios talking mostly about Halo. Note: Not bleeped, not filtered.
Anger, Sadness, Envy	Gaming	1:15 - 1:45	Rampancy.net's podcast discussing all things halo. Fun deep dives into story and gameplay.
The Dealnews Podcast	Technology, Consumer News	0:40 - 1:00	A medium-length, somewhat lighthearted take on tech news and product deals.
The Java Posse	Programming	1:00 - 1:30	Java and JVM news and sessions

Here are some podcasts I’ve just started listening to and am still evaluating:

What Maven does right

Maven teaches us several important things about what we need from a build system.

• Convention over configuration. Maven strongly encourages developers to put source files, resources, tests, and project metadata in standard locations.  Maven make life very difficult for anyone deviating from the norms.  In general, this is good, helps teamwork and collaboration, and helps for picking up a project cold.
• Defaults just work. Similar to the last entry, if you follow maven standards, then it works fine and has a reasonable assumption of defaults.
• Dependency Management. Probably the single best feature of Maven and modern build tools.  This allows a developer to specify requirements for a project without having to directly specify the physical location of those library dependencies.  This frees the build system to resolve from the network, automatically check for updates, and manage multiple versions of libraries.
• Plugins.  Easy extensibility is key to Maven.  In fact, most of its internals actually exist as plugins, from compilation to Ant support to deployment.  The ability to add new, custom behavior and have it tie into your builds is fantastic.

What Maven does wrong

There are some pretty big gotchas in Maven.  Nothing insurmountable, but frustrating nonetheless.  And before you say “It’s open source, fix it yourself!” know that it is not that simple.  There may be resistance to a certain change, for example, from “the establishment” or some issues and Maven’s solutions are fundamentally tricky.

• Outside the ordinary is very hard. Doing anything beyond the standard use cases requires an arcane knowledge of plugins.  All of a sudden, Maven’s configuration-based approach falls down, and things become easier to do in code — ie, you have to write a plugin.  But don’t think you can use the nifty ant-scripted mojos for that plugin– for example, for compilation, there isn’t a standard way to get the classpath into the ant script.
• Dependency Management. Yep, the same benefit is a detriment.  Or, at the very least, Maven’s handling of it.  Several things fall in here.  The ones I can recall are:
  • Transitive dependencies prove very tricky and make for lots of classloading troubles.  Adding a single dependency to a POM can really change the entire dependency graph of  a project.
  • There is no way to simply say “I want the latest of library XX”.  On the one hand, Maven makes sense here; you should usually know exactly which version of software you are building against.  But there are cases, for example, due to a lack of maturity, where having to know that version number is just an annoyance.  Ivy apparently has an intermediate option here, where you can specify latest, but when a build happens, it records what that version was.
• Long-standing bugs. Maven suffers a bit from what other mature open-source products hit upon.  Whether it is loss of momentum for something that works well enough or that too many are depending on the quirks, there are lots of oddities and issues left in core plugins.  A perfect example is maven-antrun-plugin, which only sets its classpath once per maven run, regardless of how many POMs reference it.
• Documentation bugs. Some of the Maven docs are a bit light on details.  Part of it may be Maven’s built-in site creation, which leads to some sites that have lots of links but are pretty information-sparse.  Other times, many common scenarios are presented, but some of the edge cases are glossed over.  Related:  looking for a list of available Maven properties for use in your POM is tricky because of Maven’s dynamic nature.  But a simple guide describing common ones and how to construct others would be great.

Summary

Generally, what Maven teaches us is that you need to fully embrace Maven to get the full benefit of Maven.  Once you get the hang of the Maven way, things go much more smoothly.  That is not unexpected, but it is uncomfortable.  But there are times where you have to fight — deploying to multiple load-balanced servers, for example, and you end up with some nasty scripts and configuration on top of a previously elegant solution.

The important thing is, though, that Maven does work.  It’s not too much of a bear to get started with, has great defaults, and it has some compelling solutions to annoying problems.

So, can Maven be fixed?  Should it be fixed, or should a build system start from scratch?  More on that next time.

! With JavaFX 1.2, some of the steps have changed. I will post a new entry covering the differences shortly.

Build / Compile

We use Maven as our build system, so JavaFX compilation must coexist with these.

Upload Dependencies to a Maven repository

First, we took every single Jar file in the JavaFX SDK 1.1 and uploaded them into Nexus, our development Maven repository. We took all jars from lib/shared and lib/desktop, uploaded them with groupID of javafx, artifactID matching the Jar name, version 1.1.

Building alongside Java code

To combat an explosion of modules, we determined that we wanted to have a src/main/fx source folder that is compiled and used right alongside src/main/java and src/main/resources. Furthermore, the JavaFX code needs to be able to refer to classes and interfaces in the same module as well as in any maven dependencies.

Our first attempt was to use the seemingly perfect fit, the m2-javafxc maven plugin. Early attempts seemed workable, but things started to fall apart and we had to abandon. Here are some of the issues:

1. m2-javafxc is based on the maven-plexus-compiler. This compiler will only run once per module. So we were unable to have src/main/java and src/main/fx side-by-side
2. m2-javafxc filters out anything other than .fx files. So we couldn’t have java and fx intermingled inside a single source folder.
3. Unfortunately, m2-javafxc is supported by only one individual, and barely used by the community. While the codebase is not large or complicated, this does represent a bit of a risk.

Next, we we noticed that the SDK includes an ant task, something easily runnable in maven. So, we built up a working ant script. If you look carefully, you will notice it takes three parameters. These are covered below.

<project name="compile-jfx" basedir="." xmlns:artifact="urn:maven-artifact-ant">
 
	<target name="compile.jfx" depends="check-if-should-build" if="should-build">
		<path id="javafxc.class.path">
			<fileset dir="${localRepo}">
				<include name="javafx/**/${javafx.version}/*-${javafx.version}.jar" />
			</fileset>
			<pathelement path="${compile.classpath}" />
		</path>
 
		<echo message="localRepo: ${localRepo}" />
		<echo message="jfx ver: ${javafx.version}" />
		<property name="compiler.class.path" refid="javafxc.class.path" />
 
		<echo message="jfxc classpath: ${compiler.class.path}" />
 
		<!-- create output directories: -->
		<mkdir dir="target/fxclasses" />
		<mkdir dir="target/classes" />
		<mkdir dir="target/clover/classes" />
 
		<taskdef resource="javafxc-ant-task.properties" classpathref="javafxc.class.path" />
 
		<javafxc srcdir="src/main/fx" destdir="target/fxclasses" includes="**/*.fx" compilerclasspath="${compiler.class.path}" />
 
		<!-- copy output files to two places to deal with clovery issues: -->
		<fileset dir="target/fxclasses" id="fxclasses" />
 
		<copy todir="target/classes">
			<fileset refid="fxclasses" />
		</copy>
		<copy todir="target/clover/classes">
			<fileset refid="fxclasses" />
		</copy>
	</target>
 
	<target name="check-if-should-build">
		<available file="src/main/fx" property="should-build" />
		<echo message="should-build: ${should-build}" />
	</target>
</project>

To integrate into maven, we use the following snippet. It ties into the standard lifecycle, as you see, and happens just after src/main/java is compiled. It supplies three parameters to the ant script:

• compile.classpath — the modules’s dependecy classpath
• localRepo — the root of the local repository
• javafx.vesion — the version of JavaFX to build with.

The last two parameters are used in the script to build the classpath to insure all the JavaFX libraries are present during compilation.

            <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-antrun-plugin</artifactId>
               <version>1.1</version>
               <executions>
                   <execution>
                       <id>ant-process-classes</id>
                       <phase>compile</phase>
                       <configuration>
                           <tasks>
                            <property name="compile.classpath" refid="maven.compile.classpath"/>
                            <property name="localRepo" value="${settings.localRepository}"/>
                            <property name="javafx.version" value="${javafx.version}"/>
 
                            <ant antfile="javafxc.build.xml">
                                <target name="compile.jfx" />
                            </ant>
                           </tasks>
                       </configuration>
                       <goals>
                           <goal>run</goal>
                       </goals>
                   </execution>
               </executions>
               <dependencies>
                    <!-- needed to compile javafx -->
                    <dependency>
                        <groupId>javafx</groupId>
                        <artifactId>javafxc</artifactId>
                        <version>${javafx.version}</version>
                    </dependency>
                    <dependency>
                        <groupId>javafx</groupId>
                        <artifactId>javafxrt</artifactId>
                        <version>${javafx.version}</version>
                    </dependency>
                    <dependency>
                        <groupId>javafx</groupId>
                        <artifactId>scenario</artifactId>
                        <version>${javafx.version}</version>
                    </dependency>
               </dependencies>
           </plugin>

Working Around Bugs

Ant Mojo

Next, we tried to wrap the above into a Maven plugin via the nifty Ant script-driven Mojo concept. However, I could not specify dependencies as I could with a Java mojo, and I was unable to get maven to pass the compile classpath into the script

maven-antrun-plugin

It turns out, if you have a multimodule project (we do) and you have multiple invocations of maven-antrun-plugin, the classpath gets set once, by the first run. We had the choice of putting every dependency on every antrun, or the light hack of having an empty antrun in the parent project with every dependency specified.

Clover

When doing a build that includes Clover numbers, clover changes the build classpath to include the artifact with the clover classifier instead of the regular one. We were putting our result classes directly into target/classes

javafxc crash

A dependency on org.apache.felix:org.osgi.compendium will cause the javafxc ant task to crash, hard, with a JVM dump. I suspect it is the javax-servlet 1.0.0, but I’m too lazy to prove that.

+- org.apache.felix:org.osgi.compendium:jar:1.2.0:compile
|  +- org.apache.felix:javax.servlet:jar:1.0.0:compile
|  \- org.apache.felix:org.osgi.foundation:jar:1.2.0:compile

OSGi / Runtime

The above gets us to a compiling and building state. However, our target platform is OSGi, specifically the Felix implementation. We need to be able to supply the JavaFX runtime classes to other bundles.

The javafx-runtime bundle

Rather than packaging each SDK jar individually into a bundle, we just dropped all of them into a single mega bundle. The following POM accomplishes this:

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <parent>
        <artifactId>PT2</artifactId>
        <groupId>org.bjc.es</groupId>
        <version>1.11.0-SNAPSHOT</version>
    </parent>
 
    <modelVersion>4.0.0</modelVersion>
    <artifactId>org.bjc.pt2.javafx-runtime</artifactId>
    <name>org.bjc.pt2.javafx-runtime</name>
 
    <!-- the <packaging> pulls bundle from the parent's properties -->
    <packaging>${packaging}</packaging>
 
    <properties>
        <packaging>bundle</packaging>
        <clover-percentage>-100</clover-percentage>
    </properties>
 
    <description>
        This bundle simply wraps the various javafx-compiled jars as a bundle.
    </description>
    <dependencies>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>decora-d3d</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>decora-hw</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>decora-ogl</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>javafx-swing</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>javafxc</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <!--
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>javafxdoc</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        -->
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>gluegen-rt</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>scenario</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>jogl</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>jmc</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>javafxgui</artifactId>
          <version>${javafx.version}</version>
        </dependency>
        <dependency>
          <groupId>javafx</groupId>
          <artifactId>javafxrt</artifactId>
          <version>${javafx.version}</version>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <extensions>true</extensions>
                <configuration>
                    <instructions>
                        <Bundle-SymbolicName>
                            ${pom.artifactId}
                        </Bundle-SymbolicName>
                        <!-- embed all compile and runtime scope dependencies -->
                        <!-- <Embed-Dependency>*;scope=compile;artifactId=!log4j|javafxc</Embed-Dependency> -->
                        <Import-Package>
                            com.sun.imageio.plugins.gif;resolution:=optional,
                            javax.imageio.*,
                            javax.swing.*,
                            javax.sound.*,
                            javax.xml.parsers,
                            javax.media.*;resolution:=optional,
                            javax.script.*;resolution:=optional,
                            netscape.javascript.*;resolution:=optional,
                            sun.*;resolution:=optional,
                            com.sun.javafx.api;resolution:=optional,
                            com.sun.javafx.runtime.adapter;resolution:=optional,
                            org.jdesktop.applet.util;resolution:=optional,
                            org.jdesktop.animation.timing.*;resolution:=optional,
                            org.xml.sax.*;resolution:=optional,
                        </Import-Package>
 
                        <Export-Package>
                            com.sun.gluegen.*,
                            !com.sun.javafx.runtime.adapter,
                            !com.sun.javafx.runtime.liveconnect,
                            !com.sun.javafx.runtime.provider,
                            !com.sun.javafx.api.*,
                            com.sun.javafx.*,
                            com.sun.embeddedswing,
                            com.sun.media.*,
                            com.sun.medialib.*,
                            com.sun.opengl.*,
                            com.sun.scenario.*,
                            com.sun.stylesheet.*,
                            javax.media.opengl.*,
                            org.jdesktop.layout,
                            !javafx.fxunit,
                            javafx.*,
                        </Export-Package>
                    </instructions>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

You can alternately use Eclipse to export a bundle like this, see the post Running a JavaFX script from an OSGi bundle– generally a good article, but slightly skewed from our purpose.

The bundle created above is not quite perfect; some imports marked optional are probably not optional, but are for parts we aren’t using just yet, like sound, or applets. It is missing all the native code shipped with the SDK, which probably has a performance impact. We also haven’t tested a fully-featured screen yet. Finally, there is another problem, which we’ll see in the next section.

Integrating JavaFX into a Swing Application

I can’t create a Scene!

There is a pretty nice article called How to Use JavaFX in Your Swing Application on the main JavaFX blog. It gives details for how to convert a Scene subclass into a JComponent for use in a swing app. The only problem with that: With the javafx-runtime bundle above, I always get a NullPointerException during some StyleSheet intialization. Even when we do it from the command-line, the result is the same. Again, the javafx-runtime bundle is not quite perfect, and I think that this bears that out.

Getting the JComponent

So, we had a workaround: Extend CustomNode, then create a Scene in Java and inject the custom node in. The class below has a field called node, which is of type javafx.scene.Node, set in by Spring (see next section). We steal some of the code from the above link to help with the final extraction. Also note, we had to duplicate SingletonSequence.java in our package, since it is package-protected in the SDK.

        Scene scene = new Scene(true);
 
        Sequence<Node> seq = new SingletonSequence<Node>(TypeInfo.getTypeInfo(Node.class), node);
        scene.get$content().setAsSequenceFromLiteral(seq);
        scene.initialize$();
 
        // stolen from JFXPanel.java by Richard Bair and Jasper Potts:
 
        String helperName = "com.sun.javafx.scene.JSGPanelSceneImpl";
        FXClassType type = FXContext.getInstance().findClass(helperName);
        FXObjectValue panelSceneImpl = type.allocate();
        panelSceneImpl.initVar("scene", FXLocal.getContext().mirrorOf(scene));
        panelSceneImpl.initialize();
 
        FXValue jsgPanelV = type.getVariable("jsgPanel").getValue(panelSceneImpl);
        JComponent jsgPanel = (JComponent) ((FXLocal.ObjectValue) jsgPanelV).asObject()

Working with Spring

The last piece of the puzzle is the ability to allow Spring to create JavaFX instances and set properties on them. Here is an example JavaFX class:

package whatever;
 
import javafx.scene.*;
import javafx.scene.paint.*;
import javafx.scene.shape.*;
import javafx.scene.text.*;
 
public class EDText extends CustomNode {
    var text:String = Dialog.MESSAGE;
 
    override public function create():Node {
        return Group {
            content: [
                Rectangle {
                    width: 300
                    height: 200
                    fill: Color.BLUE
                },
                Text {
                    x: 20
                    y: 20
                    content: bind text
                    fill: Color.WHITE
                }
            ]
        }; // endgroup
    }
 
    function setDisplayString(newValue:String) {
        text = newValue;
    }
}

It has a single operation, setDisplayString(). Then came this Spring config snippet to access it:

    <bean id="edNode" class="org.bjc.pt2.authentication.ui.EDText">
        <property name="displayString" value="set a value from spring!"/>
    </bean>

… which of course doesn’t work. JavaFX infers that the setter has a return value because none was specified. Spring is looking for public void setDisplayString(String) but finds public string setDisplayString(String) and complains. Minor tweak to the JavaFX code for the function declaration:

 function setDisplayString(newValue:String):Void {

And it’s all happy!

Maven Adoption Curve (Alex Miller, coworker at MetaMatrix)
Maven and Ivy (Ryan Senior, coworker at BJC)

I was trying to think of the ideal build system.  I won’t pretend that I’m going to get there in this post.  Instead, I’ll enumerate what we do every day and what we need from a build system so as to start thinking about the ideal system.

So, to the brainstorming.  Here’s what we do in the regular process of our osgi bundle development:

1. Obtain dependencies
2. Compile java source
3. Compile javafx source
4. Generate metadata / configuration data
5. Make jar files
6. Upload jar files to central repository
7. Upload jar files to deployment location
8. Update remote (OBR) xml file with information about uploaded jar
9. Generate reports about the quality of the source (clover, PMD, checkstyle, etc)
10. check out from CVS / source control
11. check in to CVS / source control
12. tag CVS / source control
13. manage versions and releases

I’m sure there are more.  Obviously, under web development, you’d deal with wars and their deployment.  We have ssh tasks to run code on the server.  We even have some install/run stuff that works pretty well.

You may have guessed we use maven.  Maven is so close, but just not there.  It is frustrating, performs a lot of magic, and just falls down in annoying ways.  We have gotten it to do all of the above, some of it is just not pretty.

Next episode, I’ll go into Maven and what it does well and what it does poorly.  Stay tuned!

I’m sure I’m rewriting history as I go to make myself appear in a more positive light, but the more I think about it, the more it seems I just didn’t have my wits about me.  Now, don’t get me wrong, I wasn’t up to snuff for the position for some pretty significant other reasons (like my hate/hate relationship with Design Patterns), but I’ll explore those issues at another time.

To set the stage:  I don’t know if jet lag is due to travel time, traveling at night, lack of sleep, or changing time zones, but I did all of them, and I was pretty draggy in the morning.

Except I didn’t realize that.  I had no edge, no sharpness, no wit.  I said idiotic things, couldn’t explain basic concepts, and would talk about things too long and then just trail off…

A prime example of my condition was when I was asked to explain the difference in usage and purpose of an array and a linked list (in Java terms, ArrayList and LinkedList).  I was barely able to stammer out something about resizing and that I knew there was another big difference that I couldn’t recall at the moment (random access performance times, sorting, sublists, etc).

I should have just stopped the interview there.  But I went on, because I didn’t have the wit to know better, and the rest of the day was similar, or worse.  All along, I blithely thought things were going pretty well.

The point I’m getting at is that a programmer without a quick wit really isn’t a programmer.  It takes a lot of fast operations to access needed information and format it for the receiver of that information, whether computer or human.  Know yourself, and know what you need to do to kick yourself out of a dimwitted day.

For example, say you are reading a 5 megapixel image off the disk in order to determine its size or make a thumbnail or otherwise read metadata. Or, you could be scanning files for spell checking or search terms.  Either way, you really don’t care that the original, large, source data stays in memory. If would be great if it did, for performance’s sake, but not the end of the world if it was garbage-collected.

By default, all java references are strong references — the object on the other end of a strong reference is not garbage collected until the object containing the reference is collected.  That is where java.lang.ref.WeakReference comes in. Instead of keeping your strong reference in your object, you give it to a WeakReference instance instead. It does the dirty work of allowing the reference to be collected.

You now have a strong reference to only a WeakReference object — a relative lightweight, in memory terms.  All you have to do is make sure the data is loaded when you want, and WeakRef and the GC will take care of unloading it as needed.

So, let’s take the example of reading a large file into a string, but we don’t mind re-reading the file if memory becomes tight.

The following code assumes there is a class, FileUtils, that has a method for reading the file. Implementation of that method is left as an exercise to the reader.

import java.io.File; import java.lang.ref.WeakReference; public class LazyFileReader { private WeakReference<String> fileRef; private final String filename; public LazyFileReader(String filename) { this.filename = filename; } private String forceLoadFileData() { // force initialization; create reference String rv = FileUtils.fileToString(new File(filename)); // update weakRef: fileRef = new WeakReference<String>(rv); // **1** return rv; } public String getFileData() { String rv; if (fileRef == null) { // **2** // first loading, force: System.out.println("first loading: " + filename); rv = forceLoadFileData(); } else { // load from weakRef: rv = fileRef.get(); // **3** if (rv == null) { System.out.println("file needs reloading: " + filename); rv = forceLoadFileData(); // **4** } // endif } // endif return rv; } }

Some notes, indicated by // ** # ** comments above:

1. Note that once a WeakReference has released its data, you can’t update the reference — you must create a new one each time.
2. The very first time getFileData() is called, we don’t even have a WeakReference reference. This situation will only happen once.
3. get() is the means by which you get back the reference you put in. A null value indicates that the reference was collected and therefore needs to be recreated.
4. Note that we perform the exact same code during the first time through and the first time through after the reference was collected.

Hope that helps.