such as HTTP, the run-time environment can provide its own HTTP stack
on top of the native TCP support. If we take a few steps down in the
network protocols tree (e.g., to the level of TCP), it is safe to assume
that the run-time environment either uses the native support or does not
support the network protocol at all since, at this level, access to the native
services is mandatory.
Another example of different integration levels is in the UI where
high-level functionality (e.g., SVG graphics) may use the underlying
SVG graphics support but, if there is no native support, the run-time
environment can provide its own SVG graphics implementation on top
of low-level rendering (or choose not to support it at all). The run-time
environment widgets may map onto the native system widgets or there
could be an internal implementation of widgets on top of low-level
rendering. If we take a step down the UI levels to low-level rendering, it is
clear that, at a minimum, the run-time environment must use some native
low-level rendering mechanism which provides access to the screen.
Figure 11.2 Levels of integration in the user interface
11.3 Integration Challenges, Costs and Considerations
Let us now discuss the reality of Java ME subsystem integration - the
challenges that JSR integration engineers face and the considerations
in preferring one type of integration over another, or providing a non-
integrated JSR implementation.
There are numerous challenges in the interoperability of non-heteroge-
neous software components:
different languages - Java, C and C++
different platform idioms - Java and Symbian C++
different architectures - Java ME architecture and the Java ME subsys-
tem internal architecture compared to the Symbian OS architecture.
There are also challenges specific to each JSR, as we see in the
examples given in the rest of the chapter. The technical challenges
require a non-trivial engineering effort.