Mouse events from Java Swing report the click count
. When mouse events are generated within some click threshold (which should be an operating system setting), the click count increases. One common problem is processing single- versus double-clicks. Java does not hold back the single-click event (click count
of 1) even when a double-click (click count
of 2) may be forthcoming. This is for good reason: As well designed of a programming language that it is, Java cannot see the future.
There are techniques (documented elsewhere) for dealing with this aspect of mouse processing in Java. The impetus for this article is mouse event inconsistencies between platforms. Particularly, click counts seem to be reported differently for different events on different platforms. Read the rest of this entry »
As of this month, I have transitioned from adding gameplay features into improving usability, performance, and scalability.
Usability includes improving the game's user interface, as well as streamlining client behavior and server operation. For instance, the in-world shops and character inventory have been given a face lift. More technical issues include client network behavior and server configurability.
Performance testing measures CPU and RAM utilization on the client and server, client-server network requirements, server database/disk read/write, and graphic processing capability of the client. Performance tuning will allow the client to run smoother and reduce server-side bandwidth, CPU, and RAM requirements.
Scalability is related to performance, dealing specifically with the capability of the client, server, and network to handle increasing numbers of players (and therefore islands, creatures, battles, items, etc.).
JTextArea is a convenient Swing component to use when word-wrapping is needed. To display a list of multi-line messages, for example, the obvious solution is to use a JTextArea as the ListCellRenderer Component for a JList (within a JScrollPane). However, you will soon find that the text often does not end up word-wrapped as expected.
After reading post after post of mystic incantations, none of which actually seem to fully work, I present my solution for using a JTextArea in a JList: Don't.
Read the rest of this entry »
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
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
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.
Read the rest of this entry »
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:
- core: Networking, storage, and application framework libraries
- gui: Graphical User Interface implementation libraries
- client: RPG Client application (67% of which is client-specific GUI code)
- tools: Development helper applications
- server: RPG Server application
- other: Data structures, rules logic, and other game-supporting code
I was just perusing the Java source code (because I don't read the morning newspaper), when I discovered that
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
operation. Read the rest of this entry »