[deprecated] muddyhorse

I’m trying to pick up a bit of Android development experience. Here’s some tips for getting started from scratch.  I have a lot to learn… Read the rest of this entry »

I haven’t formulated exactly what I’m going to say, but I wanted to start a series on the Clumsy pattern in software development.  Don’t get excited, I’m neither adopting patterns as a beloved thing (that sentence needs its own post), nor am I trying to establish a new industry term.  I’ll do a Clumsy Pattern post when I come across things that are so archaic or broken that they have no right still existing. Read the rest of this entry »

I just wanted to capture the current set of podcasts I listen to. I commute two hours a day, and this set keeps me lightly stocked — Sometimes I run out for a day or two, and I rarely fall behind.

Read the rest of this entry »

Continuing the Java build systems discussion, today I want to focus on Maven, what it does well and what it does that frustrates.  We’ll get a little taste of the minimum expectations for a new build system as well.  Note:  this page may be subject to edits, as I come across more pros & cons of Maven.

Read the rest of this entry »

We had to go through a number of steps to support the combination of Maven + OSGi + Spring + JavaFX-1.1 in our Swing-based application. This document describes all the steps and technology we’ve gone through to get it working.

Read the rest of this entry »

Two recent posts on the java-weblog circuit spurred me to motion:

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.

Read the rest of this entry »

I was humbled this past week.  I went to an interview at a game company.  But I didn’t have my most valuable asset.

Read the rest of this entry »

Java’s WeakReference functionality is an easy way to handle a lot of data but not have to worry about running out of memory.  Works well in lazy-initialization situations, such as when you want to be able to read in a potentially large amount of data, but that data is not important enough that you want to guarantee that it is always immediately available.

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.