Javia blog

JAD is an acronym for Java Application Descriptor. JAR comes from Java Archive.
In the MIDP world, the JAD is a small text file (with the extension .jad) which contains a few lines of information about a Midlet application.

An example JAD file:

MIDlet-1: Menstral, /M.gif, M
MIDlet-Name: Menstral
MIDlet-Vendor: Mihai Preda
MIDlet-Version: 1.8.11
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0
MIDlet-Jar-URL: http://menstral.net/Menstral.jar
MIDlet-Jar-Size: 31105

Noteworthy inside the JAD are the MIDlet-Jar-URL line, which indicates the location of the JAR, and the MicroEdition-Configuration and MicroEdition-Profile lines, which represent the required versions of the CLDC and MIDP that the device must support in order to be able to run the application.

One way to install applications is: the phone downloads the JAD, checks whether the required versions of CLDC and MIDP are satisfied, and if the answer is positive it proceeds to download the JAR file containing the application.

Another way is to directly download the JAR. This works because every JAR contains inside a special file, the Manifest, which contains mostly the same information as the JAD. That is, the phone can do without the JAD because it can get the same information from the Manifest found in the JAR.

So, if the JAD is duplicated inside the JAR (in the Manifest), and the whole download/installation can proceed very well without the JAD, what is the reason for the JAD’s existence?

Well, the idea is that the JAD is small, but the JAR is not so small. If your phone can’t run the application (because it doesn’t satisfy the required conditions specified in the JAD), it’s better to just download the JAD to find it out (and skip the bigger JAR download in this case).

This is the only gain of using the JAD/JAR pair compared to using only the JAR: you don’t have to download the (big) JAR in the situation when your phone can’t run the application.

But here comes the surprising affirmation: the JAD is actually a bad thing, and the fact that this whole JAD concept got into the MIDP standard is a flaw, and we, as midlet developers, should favor the “JAR-only” distribution, thus driving the JAD to practical obsolescence even if it is in the standard.

Here is why the JAD is BAD:

The JAD is not needed

1. The situation when the JAD saves bandwidth by avoiding the JAR download is infrequent.

Most users download midlets that run on their device much more frequently then they download midlets that don’t run on their device. This is because at the point when they decide to download a midlet, they have strong reasons to suppose that it will run on their phone. One factor is that the web server which offers the download can detect the phone’s capabilities (e.g. by using the User-Agent info sent by the phone) and can only offer for download midlets which can run on the particular device. Another factor is that the midlets’ web page contains textual information about their requirements, such as “This midlet runs on any MIDP 1.0 mobile phone”, or “this midlet runs only on Nokia, MIDP 2.0 phones” etc, that the users can evaluate before initiating the download.

2. The JAD benefit, infrequent as it might be, is small.

Even in the (rare) situation when the JAD saves the user from downloading the JAR, it only saves a few tens of Kilobytes of bandwidth, which is not likely to make a big difference to the user. It’s not like the JAD-avoided JAR download is a must-have lifesaver feature that users simply can’t do without — quite the opposite.

3. The JAD’s benefit can be harnessed without using the JAD.

Here it gets interesting: the JAD concept isn’t needed in order to get the bandwidth save mentioned before. The same bandwidth saving can be obtained without the JAD.
This is how:
- have the archiver which creates the JAR archive always position the Manifest file at the beginning of the archive.
- have the mobile’s downloader incrementally extract the Manifest while the JAR is downloading. As soon as the Manifest has been extracted, but before the whole JAR was downloaded, inspect the Manifest to see if the device can run the application. If it can’t, stop the download without transferring the rest of the JAR, thus saving bandwidth.

The MIDP JSR, instead of the over-designed JAD contraption, could have simply used two non-normative guidelines: the java archiver (jar) should place the Manifest at the beginning of the archive, and the mobile’s software should inspect the Manifest as soon as it becomes available during the download. But I guess the standard-makers were too busy to consider the simple solution.

The JAD comes with a cost

So, we’ve seen it could have been just as good without the JAD, but one might argue: one the other hand, it’s not like having this JAD thing hurts either. Well, it does hurt:

1. The users

There are two main ways to install midlets: over the air (downloading them directly on the device), and by copying the JAR from your desktop to the phone’s filesystem using a data connection (infrared, bluetooth, usb, etc). The second way of installing can’t use the JAD, but must use the JAR. So the midlet download sites can’t offer just the JAD to their users, they must offer the JAR too (in order to support the filesystem-istall).

The user who wants to download a midlet is presented with the choice: here is the application you want, Foo.jad and Foo.jar. The user stops and thinks: which one should I choose? or maybe I have to use both? or perhaps I’ll try one and then the other, and see which one works? and what’s that jad thing anyway? etc.

I just think of all the users that installed on their phone’s filesystem only the JAD, and afterwards wandered why it doesn’t work. Even myself, before being a midlet developer I was a midlet user, and I kept installing on the phone’s filesystem both the JAD and the JAR, because I didn’t understant their roles (of course, on the phone’s filesystem the JAD was useless and ignored). It took me a few midlet installs and google searches until I realized that the JAR is enough and that I don’t need to bother with the JAD.

The general principle is: don’t make the users choose/think, and they won’t get confused.

2. The developers

The JAD adds significant complexity, even if this is not obvious at the first sight. For example, think of the conflict resolution rules for the situation when the same key has different values in the JAD and in the Manifest. Did you consider the signed midlets?

Or think about which keys should be placed only in the JAD, which ones should be placed only in the Manifest, and which ones should be placed in both the JAD and the Manifest. And the complexity applies also to the device developers who have to implement the standard.

Conclusion

I suggest that midlet distributors offer only the JAR (and drop the JAD), as this will reduce the confusion of the users.

The guidelines concerning the placement of the Manifest at the beginning of the JAR, and the early inspection of the Manifest during download should also gradually come into use.

This entry was posted on Saturday, December 2nd, 2006 at 11:38 and is filed under JavaME. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.