Java Reference
In-Depth Information
classes, possibly squeezing more code into fewer classes, and so on.
These techniques have a negative impact on the abstraction of the prob-
lem 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.
3.4.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 man-
agement for your Java application - dereferencing unused Java objects
