It’s old news that Java’s Swing GUI toolkit follows a deficient Model-View-Controller (MVC) architecture. In most cases, Swing fuses together the notion of the View and Controller, but offers a separate Model. At least, that’s what the naming convention implies. For example, JComboBox should be a View-Controller to a ComboBoxModel.
This particular case failed me today. Read the rest of this entry »
Here’s a helpful method for returning the maximum of two Comparable objects.
Do the Java APIs provide this somewhere?
/** * Return the <i>maximum</i> of the two arguments. If the arguments * are <i>equal</i> (as defined by the Comparable contract), the * <i>left-hand-side</i> argument is returned. */ public static <T extends Comparable> T max(T lhs, T rhs) { return rhs.compareTo(lhs) > 0 ? rhs : lhs; }
The cleanest way to close a Java GUI application is to dispose of all top-level resources (JFrame instances, for example) and allow the AWT/Swing thread to close itself. Calling System.exit(0) or Runtime.getRuntime().halt(0) is often prescribed, but not recommended, as it could preempt proper shutdown procedures in your application.
If your Java GUI application uses DISPOSE_ON_CLOSE mode, check that your process is exiting cleanly. If it is not, the most likely culprit is that the AWT Event Dispatch Thread is still active. This is well-known AWT/Swing behavior, but there is a scenario in which Java will refuse to shut down this thread, even with all resources closed and disposed.
I updated my development platform to Java 1.6.0_18 and noticed a disturbing font alteration in all Java applications. I’m developing in Ubuntu 9.10, which currently bundles Java 1.6.0_15 (in the sun-java6-jdk package), so I manually installed the latest for testing.
I have yet (since yesterday) to investigate whether this is Ubuntu specific. Font configuration changes were noted in the Java 1.6.0_18 Release Notes, associated with a particular bug.
Preliminary investigation implies that Java’s attitude toward font consistency has changed over time. Early Java 1.3 Physical Fonts documentation makes clear that:
The SDK’s physical fonts offer … Consistent Look and Feel: Your applications will look the same on all platforms because they will be using the same fonts. This makes testing, deployment, and support easier in a cross-platform environment.
In contrast, a more recent bug submission was thoroughly thrashed for suggesting that fonts should remain consistent across platforms and versions. This seems to contradict one of the primary tenets of the Java platform: “Write once, run anywhere”
In the future, I’ll be looking into explicitly loading a specific font set, possibly by embedding custom fonts within my application.
Today’s SLOC count is 96,060 (4,237 less than my 100k analysis and 3,501 less than yesterday). While adding several new gameplay features, I was able to streamline the implementation in several places. This SLOC drop results from isolating (and removing) a good chunk of legacy logic, rules, and display code, which was impeding the integration of new features. Most importantly, playtesters should notice more direction in the gameplay, just as soon as I can deploy the next incremental Alpha release.
This morning, I noticed that my SLOC (Source Lines of Code) chart (in the sidebar of this blog) has breached the 100k mark (100,297sloc to be exact). That count is due to drop with the pending removal of some unused tools, defunct data structures, and legacy logic. Still, I thought it might be interesting to do a quick breakdown of the basic components:
The categories are:
I was just perusing the Java source code (because I don’t read the morning newspaper), when I discovered that java.util.LinkedList.clear() is implemented to operate in linear time. The documentation does not specify its order of growth, and I intuitively assumed that a linked list clear implementation would be a constant time operation.
Could this be an artifact of early Java development, leaving a legacy of poor performance? The remainder of this article explores the potential to significantly improve application performance when using the LinkedList.clear() operation. Read the rest of this entry »
First: Unless you’re a Java developer who enjoys weekend threading and locking studies, don’t read this, unless you want your brain to melt. I’m primarily writing this for my own sake (because I am a Java concurrency junkie).
Second: There is nothing wrong with LinkedBlockingDeque. It follows all the proper behavior of a concurrent collections class (of which I’m a big fan). The situation documented here boils down to a classic concurrency scenario I simply didn’t take into account.
The Exploit: The impact to my MMORPG was that a player could force his/her character to translocate over stretches of non-navigable terrain, such as bodies of water. This would constitute a major exploit. To add to the mystery, it only happened on my development platform, not on the alpha testing network (even over the same LAN). Read the rest of this entry »
Working on my own requires me to run the gauntlet of software development. The process exposes personal and professional strengths and weaknesses, which I believe are difficult to discover in a corporate environment. An employee’s job title tends to become a shell, which can be difficult to break out of. Being responsible for every aspect of this software project (not to mention starting a potential business) reveals where I thrive and where I am lacking in experience.
Since nautical analogy is always the best way to describe a complex situation, consider the software enterprise as an 18th century ship-of-the-line. Read the rest of this entry »
In a previous article, I described a Concealed Controller Pattern, which allows Java classes to be packaged separately, while maintaining access control to certain sensitive methods. In today’s article, I discuss the shortcomings of Java’s package capabilities and present a simple pattern (the Keyed Access Pattern) for overcoming one case.
