Most operations (e.g., opening a connection to a SIM application,
exchanging APDU) result in initial processing of the internal implemen-
tation Java classes, jumping into the native code, invoking the licensee
interfaces, and returning the result.
Data that is static or does not change during the application lifecycle
(e.g., SIM security information, ATR) can be fetched from the SIM card
once, by calling the set of interfaces that are implemented by licensees.
The data is stored in the internal implementation Java classes and when-
ever it is needed by the Java application, the cached information is
fetched directly without going again into native code.
It is clear that integration with native services is mandatory in this case.
Let us try to challenge this specific implementation design approach by
suggesting an alternative - a native integration which is very similar to the
JSR APIs. Let's take it to the extreme and suggest that for each Java method
in the APDU package there would be an equivalent native function. In
other words, every Symbian OS licensee would be required to provide
their own implementation, entirely in native code.
This solution satisfies all of the factors we mentioned - strict require-
ment, performance, customizability, consistency and strategy. But it has a
significant disadvantage in that it multiplies the JSR implementation effort
by the number of licensees or by the number of APDU-package-enabled
Such an approach would fragment the Java ME platform on Symbian
OS and eventually that might have an impact on the portability of Java
Using JSR-177 SATSA APDU package, we discussed a case where inte-
gration was mandatory yet the native APIs are owned exclusively by
Symbian OS licensees or network operators. We have also seen again
the principle of Java code internal to the Java ME subsystem at one end,
native Symbian OS services at the other end, and between them layers of
native C and C++ code that is owned by the Java ME subsystem.
11.5.6 Tight Integration: JSR-180 SIP
We now discuss an additional JSR integration type in which all the
required functionality is fully available as a native Symbian OS service and