|
Java ME - Pros and Cons
These pros and cons are based on available literature, specifications
from Sun and practical experience.
| |
Java in general
(compared to C/C++) |
Java ME MIDP/CLDC |
| Pros |
- A much cleaner object-oriented language than C++, that's more like C
plus object oriented constructs
- It has integrated multi-threading support, which means it becomes simple,
natural and portable to use
- Java is strictly typed, supports object
references instead of pointers and doesn't need/support explicit deallocation of heap data
(which though has arguable efficiency drawbacks), leading to less hard
to find "silly" bugs and more time to focus on the logical bugs
- Primitive data types have pre-defined sizes (instead of C/C++'s
arbitrary sizes) increasing portability
- Real boolean and string types (yet with a sometimes awkward
distinction between strings and string buffers)
- Labelled breaks for getting out of multi-level loops
- Doesn't use include files (the source files contain all information
needed)
- Development tools are very good, and free (see
Resources and
NetBeans)
|
- Supported by billions of mobile phones, and it's the clearly
dominating mobile application platform, even though the awareness of
this is relatively low
- Applications can be offered via your own site, via content providers
or operators, and there's no lock-in to certain operators like with BREW
and iPhone
applications
- Provides much better interaction than browser-based client/server
solutions, including support for offline access
- Access to local functionality like Bluetooth, camera, microphone, speaker, PIM data,
sensors, GPS, file system etc, which you can't from a browser-based solution
- Much quicker to deploy and upgrade than embedded applications, that often need
to follow strict operator specifications and very rigorous testing by
manufacturers, and it takes a much longer time to bring them to market
- Very quick and easy to test in Java Wireless Toolkit and on phones
- NetBeans provides a RAD-like tool for creating
high-level UI focused
applications quickly
- E.g. J2ME Polish can be used to customize the UI and handle device differences of MIDlets in a very flexible way
|
| Cons |
- The base statements and operators are pretty much exact copies of
ditto in C/C++, which for instance means that the switch statement only takes a numeric expression and can't handle
condition ranges, object comparisons etc. See Visual Basic's select
for how a proper options statement should work
- Dynamic and associative arrays and data sets should arguably have been
integrated in the language instead of being classes (see e.g. PHP),
simplifying syntax
- Operator overloading is not supported, making the code verbose when dealing with e.g. data sets and complex numeric values (like 3D coordinates); such overloading has drawbacks
too, so there are reasons why it's not there
- There are no unsigned longs and ints; they are very
important when calling native code; not an issue for Java ME
though...
|
- Being interpreted (but not in newer phones), Java ME applications
may run slowly compared to native
(machine code; e.g. BREW) applications; that can have an impact on e.g.
advanced games; for communication/productivity applications this is less
of a problem (if even noticeable)
- Phones support different flavors of CLDC, MIDP and JSRs, meaning you either have to
test for different functionality and adapt dynamically, or make
different applications for different phones; verifying this can be very
time-consuming and costly; JTWI has partly remedied this, but not fully in
terms of e.g. multimedia, and there are also outright bugs that need to be circumvented
- MIDP only supports a few (yet in my opinion enough) collection classes, namely Enumeration, Stack, Vector and Hashtable,
probably to minimize the class library size, but this means J2SE code
porting becomes more complex
- The high-level UI is not customizable, meaning you in many cases
need to use Canvas instead, increasing application complexity
- The UI is neither compatible with Java SE, making porting of such
core harder
- To officially support many phones you simply have to test on all
those phones to be sure it really works; this is because there are
several providers of Java ME KVMs as well as different levels of
functionality in different phones
|
|
