It should be obvious that there are no JSRs in the DoJa world. There
are simply versions of DoJa with more or less functionality as the case
requires - as mentioned above, fragmentation is far less of an issue when
you control all aspects of the manufacturing process! For the same reason,
and unlike with MIDP, new versions of the DoJa profile do not necessarily
have to be backwards compatible; indeed, it is very common to have
classes or packages re-named, classes moved to another package or
simply removed entirely between one version release and another!
Most readers are already familiar with Java ME development using
some combination of MIDP and CLDC. This makes learning DoJa a
fairly simple task once you understand what the limitations are. To give
some context, Sections 7.3, 7.4, 7.5, 7.6 and 7.7 specifically discuss
DoJa2.5oe - the latest overseas edition available. Many of the functional
limitations outlined in the list below are removed or relaxed in the
versions internal to Japan (such as Bluetooth APIs being available) but for
those of us who don't live in Japan, the 2.5oe API is all we get.
With that in mind, let's look at some of the main restrictions that can
tend to frustrate newcomers from an MIDP background:
There is no multitasking so only one application may be running at
any one time.
The size of the actual JAR file can be no more than 30 KB - larger
JARs are simply not installed.
There is no record management system (RMS) to speak of - the nearest
equivalent is a binary random access file, called the Scratchpad,
limited to a maximum of 200 KB in size.
You may open sockets over OBEX or HTTP but HTTP sockets can
only be opened to the same server from which the application was
When you have an HTTP connection, data transfer is limited to 5 KB
upload and 10 KB download.
There is no access to PIM data, such as the Calendar, and although you
can addnew phonebook entries, you can't read from the phonebook.
There is no access to Bluetooth.
These restrictions can be a bit daunting at first, but when you consider
that thousands of i-Appli have already been written and sold creating
a multi-billion yen industry, 6 it's clear that developers have devised a
number of workarounds over time. Probably the biggest hurdle is the JAR
size limitation, which often directly affects application architecture as
well as porting strategies.