|
1 <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
|
2 <html> |
|
3 <head> |
|
4 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
|
5 <meta name="Author" content="Nokia"> |
|
6 <title>Runtime support API</title> |
|
7 </head> |
|
8 <body> |
|
9 Runtime Support hides differences between different runtime implementations |
|
10 from the API developer. |
|
11 <p> |
|
12 Runtime Support aligns different runtimes (including different JVMs so that |
|
13 API implementations can rely on them in all runtimes (MIDP3 Runtime, CDC main, |
|
14 eRCP Runtime) have different implementations of Runtime support API, but |
|
15 runtime differences are hidden behind Runtime support API. Runtime Support also |
|
16 provides API for hiding differences between different JVM vendors and for |
|
17 hiding some differnces between CLDC and CDC. |
|
18 <p> |
|
19 Runtime Support provides following services: |
|
20 <li>Application related services.</li> |
|
21 <li>Special services provided by the JVM.</li> |
|
22 <li>System property extension mechanism.</li> |
|
23 <p> |
|
24 <h2>Application related services</h2> |
|
25 Application related services provides utilities for getting application specific |
|
26 static information like name, uid, vendor, version etc. Application related |
|
27 services provides also some utilities that are application lifetime dependent |
|
28 like ability receive a notification when the application is about to close. |
|
29 <p> |
|
30 For further details see {@link com.nokia.mj.impl.rt.support.ApplicationInfo} |
|
31 or {@link com.nokia.mj.impl.rt.support.ApplicationUtils}. |
|
32 <h2>JVM services</h2> |
|
33 The basic idea is to provide helper utilities for cases where there is need to |
|
34 use different implementation depending on the used JVM or the used configuration. |
|
35 In other words the underlying JVM is tried to hide from the API developer. |
|
36 <p> |
|
37 There are two cases where port layer is needed: |
|
38 <li>Some standard API either is used differently or is missing from certain |
|
39 configuration. This is most commonly needed to hide differences between CDC |
|
40 and CLDC. For example System.loadLibrary doesn't exist in the CLDC and |
|
41 therefore when using CLDC JVM we need to call some proprietary API provided by |
|
42 the JVM vendor, which must be hidden from the API developers. Another example |
|
43 is Class.forName. If the we are using CDC JVM and we are trying to load a class |
|
44 which is int 'normal' classpath from a class that is in the bootclass path, |
|
45 we need to provide the class loader. In CLDC we don't have class loaders, so |
|
46 the Runtime support variates the usage of Class.forName in different |
|
47 configurations.</li> |
|
48 <li>The JVM provides some proprietary APIs to do some things in more |
|
49 advanced/faster way than it is possible using the standard Java APIs. One |
|
50 example could be {@link com.nokia.mj.impl.rt.support.NativeMemoryBlock}, which |
|
51 provides a way to read some resource from the jar file and store the content |
|
52 in a native memory block instead of copying the content to Java side. |
|
53 <p> |
|
54 JVM services are divided into two different classes: |
|
55 {@link com.nokia.mj.impl.rt.support.Jvm} and |
|
56 {@link com.nokia.mj.impl.rt.support.JvmInternal}. <code>Jvm</code> is meant |
|
57 for all API developers while <code>JvmInternal</code> is meant only for |
|
58 Runtime's internal usage. |
|
59 <h3>Finalizers</h3> |
|
60 Some public API are defined so that implementation requires usage of |
|
61 Java finalization feature. Since finalization is not part of CLDC, the |
|
62 Runtime Support provides a common way to hide VM specific implemetation from |
|
63 the API developer. The provided way works also in case where the used |
|
64 configuration (e.g. CDC) officially supports finalization. |
|
65 <p> |
|
66 For further details see {@link com.nokia.mj.impl.rt.support.Finalizer}. |
|
67 <h2>System property extension mechanism</h2> |
|
68 Many APIs need to introduce new system properties into the system. Since the |
|
69 JVM is delivered in binary format, it is needed a mechanism to extend |
|
70 (and overwrite) existing system properties. |
|
71 <p> |
|
72 System properties can be divided into three categories: |
|
73 <li>Static ones, that will never change during the runtime of the JVM (e.g. |
|
74 microedition.jtwi.version).</li> |
|
75 <li>Dynamic static ones, that will be solved during first query, but will |
|
76 not change after that during the runtime of the JVM |
|
77 (e.g. microedition.platform).</li> |
|
78 <li>Dynamic ones, that may change any time during the runtime of the JVM |
|
79 (e.g. com.nokia.memoryramfree)</li> |
|
80 <p> |
|
81 No matter which category the system property belongs to, it is stored into |
|
82 the hash table from where it can be found fast. Only the value of the property |
|
83 tells if the property is static or dynamic. |
|
84 <p> |
|
85 The usage of System property extension mechanism is explained in more detailed |
|
86 in {@link com.nokia.mj.impl.rt.support.SystemPropertyProvider here}. |
|
87 <h2>Runtime Support wiki pages</h2> |
|
88 Here is a link to the Wiki pages of the |
|
89 <a href="http://wikis.in.nokia.com/MIDPEvolution/ArchitectureRuntimeSupport" |
|
90 target="_top">Runtime Support</a>. |
|
91 </body> |
|
92 </html> |