Enter Java ME on Symbian OS : Proprietary JAD Attributes, Computing Capabilities of Java ME on Symbian OS

1. Proprietary JAD Attributes

There are various edge cases that are not handled by Java ME specifications but are handled by S60-specific JAD attributes (see Table 1 for details of some attributes).

Support for these attributes may vary between S60 devices. For example, S60 5th Edition introduced a few JAD attributes that support screen orientation and scaling. These JAD attributes are also supported on S60 3rd Edition FP2 devices released after S60 5th Edition. Earlier S60 3rd Edition FP2 devices do not support those attributes.

Developers can take benefit of other proprietary JAD attributes after verifying that they are supported on the target device. For more information and the full list of proprietary JAD attributes, please refer to Forum Nokia and the online Java Developer Library.

2. Computing Capabilities of Java ME on Symbian OS

Unlike many feature phones, Java ME on Symbian OS provides Java applications with an execution environment that has no fixed limit on Java computing resources. Developers can focus on the main task of their application rather than on managing resource utilization and working around various computing constraints.

If you have ever ported an MIDP application from one feature phone to another, you probably understand what we mean and still remember the pain. If a certain JSR is not supported, you cannot target a certain device using Java ME but constraints on computing resources are a different story. They make you do things that are not necessary in order to get you closer to your goal of the application's main use cases.

From a software engineering point of view, to build an application, you need to create an abstraction of the problem domain as close as possible to real life. Then you apply relations between the various entities and lay down the execution path that enables each of the application's use cases. But when you have computing constraints, you find yourself resorting to workarounds and tricks to reduce resource utilization, such as manipulating the JAR size, the RMS size, the number of threads, the number of connections, and so on. On low-end devices, computing constraints can be a real nuisance. Not so with Java ME on Symbian OS. In general, Java ME on Symbian OS poses no limits on computing resources.

2.1. Constraints on JAR Size

There is no predefined limit on the size of the MIDlet suite's JAR file. Even an extremely large Java application (e.g., 700 KB) will be installed successfully on a Symbian smartphone.

There are low-end phones and feature phones (not Symbian smart-phones) which limit the JAR size to 120 KB. As a developer, you find yourself checking every few builds to ensure you have not exceeded the 120 KB limit. So you start resorting to various techniques that restrict your application from growing in size. For example, each class has an overhead, so developers may avoid defining Java interfaces or abstract classes, possibly squeezing more code into fewer classes, and so on. These techniques have a negative impact on the abstraction of the problem domain and can make the code less readable, less maintainable and less extendable.

Additionally, images and other resources in the JAR demand a high price when there are fixed limits, so you resort to converting resources to smaller formats but these probably also have an impact on quality. Reducing the size of images by using PNG-8 instead of PNG-32 makes the images smaller but may also reduce their quality. For example, the background image for a Java game would not be as visually compelling as it could be.

These constraints don't apply when you use Java ME on Symbian OS. There's no need to think twice before adding another class to improve your abstraction. An additional class, however big it is, does not pose any problem to the installation or run-time environment. You can code freely and safely without counting the number of classes and resorting to code-size-reduction tricks. The same goes for static resources, such as images – naturally, you need to consider the footprint (and if the format you choose is supported), but not having a JAR size limit means that you can be more relaxed and put much more emphasis on the quality of the images rather than how big they are.

A traditional solution for reducing the JAR size by 10–20% is to use an obfuscator. While obfuscators achieve a substantial reduction of code size, you need to remember that the primary target of obfuscation is to protect your intellectual property by preventing decompilation and reverse engineering of your code.

The lack of constraint does not mean that JAR size is not relevant – a sizeable JAR takes longer for the user to download and the installed application inevitably occupies significant amounts of memory. But you can have a much more relaxed approach on Symbian smartphones and give higher priority to abstraction, maintainability, quality, and so on.

2.2. Constraints on Heap Size

There is no predefined limit on the application heap size or on the number and stack size of Java threads. Of course, eventually you will run out of memory but you need to do something quite intense and memory consuming to get to that point. The Java Objects heap is allocated a certain size on application start up. If there is not enough memory to allocate a new object, after a few memory allocations and garbage collections, the CLDC-HI VM expands the application's Java heap to allow more memory allocations. The process is reversible: the heap can shrink, in order to free resources back to the system.

This does not mean that there is no need to plan proper memory management for your Java application – dereferencing unused Java objects and closing resources remains valid and important, just as on any other Java ME platform.

2.3. Constraints on Threads

There is no fixed limit to the number of threads you can create or run. As always, you need to be considerate of resource utilization, but another Java thread is unlikely to make a significant difference. On some low-end platforms, you might have a small pool of Java threads that you would use repeatedly for different tasks. On Symbian OS, your code can have Java threads according to its needs, without the burden of thread pool management.

Of course, this does not mean that you should not consider cooperative multithreading in your application. But if a thread is what you need for the proper design or task execution in your application, then you should use it.

2.4. Constraints on Number of Connections

Sockets and other connections are also a scarce resource on low-end platforms. For that reason, some devices impose a predefined limit on the number of connections that an application can open. For example, a Java application on such a platform may only be able to open two connections at a time, which might not be enough for some applications. Again, Java ME on Symbian OS lets you open as many connections as you need for your application.

This does not mean you should not dispose of connections that are no longer needed. For example, once an application completes a web services transaction and the connection is no longer needed, you need to dispose of the connection in order to release all acquired resources.