Potential Blog

Java Web Start should be a major benefit for Java application developers and, more importantly, end users. The JWS concept is simple: A configuration file (JNLP) sitting on a Web server defines how to install, update, and launch a Java application. At each launch, application resources are fetched, installed, and updated for the user as automatically as possible.

Great concept, but the reality of Sun’s JWS implementation is abysmal. End users are forced though a gauntlet of obstacles, in which any error tends to be catastrophic.

Assume JWS is installed and browser integration is configured correctly for all browsers (a MIME type must be set up to launch JWS when a JNLP file is clicked). When a JNLP is first launched, shortcuts are installed on the user’s desktop and in menus, as directed by the JNLP (barring some bugs). These shortcuts conveniently launch the application. However, there are several bugs against JWS in which these shortcuts become corrupted. The result is a cryptic error that implies the application is broken, which is enough to prevent most end users from using your application. The situation is not easily repaired (as discussed below).

One such case prompted this article (rant): Upgrading from Java 5 to Java 6 caused all JWS application shortcuts to become broken. To correct the situation, users must find the JWS Viewer application. I couldn’t find the shortcut in Windows, so had to run “javaws -viewer” on the command line. This could be a friendly viewer of installed Java applications, but is actually considered a sub-dialog of the hideous Java Control Panel, showing the JWS “application cache.” The applications had to be removed, then the original JNLP link clicked to initiate a new installation. If the user cannot perform these steps, and does not know the JNLP URL, the error is unrecoverable.

The same problem can occur in several other ways, such as renaming shortcuts, or making several JNLP changes. The end result is an error shown to the user, implying the application is broken. In all cases, JWS should be smart enough to detect the corrupted shortcut and reinstall the application. Instead, an exception and stack trace are shown to the user. This is a completely unacceptable scenario for the end user.

Another problem occurs if the user saves the actual JNLP file locally, then launches from that file. Even though the JNLP has the full URL information of the application resources, JWS does not go to the source when the JNLP is clicked locally. Thus, no updates are ever discovered, which breaks the basic contract of a so-called “online” JWS application: the user will always have the latest version.Overall, Java Web Start should be redesigned to provide a robust user experience. Otherwise, I don’t anticipate moving MMORPG out of alpha with JWS. An alternative is to simply create a launcher script (or Windows executable) that checks resources before launching the application. However, Java developers shouldn’t have to reinvent this wheel.

Resources:
This bug should never have been closed: Sun Bug 6446676
This bug appears to replace the previous: Sun Bug 6563938
Similar broken shortcut bug: Sun Bug 6549428

The MMORPG Alpha testing server is up, running the latest development code. I’ve done almost no testing of this version, so watch out for sharp edges.

The biggest update to look for is the functioning of shops within towns. Donate resources to the Civic Works “shop” to develop the town, enabling more shops. This might be difficult to do, due to the dearth of content. Also, the Civic Works interface does not work exactly right, so just put up with it until I redesign that shop.

Also look for the Settlement Project “shop.” This is another resource donation-based civic works project. After a trail is built, a remote settlement can be established. The settlement becomes a new town elsewhere in the world, which is how towns proliferate across the landscape. Trail and road building won’t actually show up on the surface yet. Once the road is complete, travel services become available to the next town. Give it a try, but don’t expect it to work yet.

I do not anticipate any more development until next week. Don’t eat too much turkey, and make sure to bundle up Friday morning.

As I’m sure everyone has noticed by now, the MMORPG Alpha testing server is down. This was not a software problem, but a hardware malfunction(*). I spent the weekend moving drives and machines around and restoring development services, such as the Subversion repository.

At this point, everything is back up, except for the Alpha test server. I plan to restart the server tomorrow, if at all possible, with the initial Town Dynamics features.

On the positive side, backup and restore worked.

(* A hardware malfunction caused by human error … namely, mine. Never, ever, attempt to pull a video card from a running machine, or you might just fry the motherboard.)

It has been some time since Alpha2 was announced. As Alpha2 continues, it’s a goal of mine to communicate what is happening more regularly.

Design Goal: Dynamics
The world of MMORPG is not a static place, but rather a dynamic environment, influenced by player choices.

This differs from most classic RPGs, in which the world is rigidly defined from the point you insert the cartridge. The MMORPG dynamics system offers more interesting MMO gameplay.

The next major feature to be introduced (relatively soon) is town dynamics. This component of this dynamic design involves town proliferation, as well as shops and services. At this point, the initial implementation is functional, minus a couple features. I’ll post more details when it’s ready for alpha playtesting.