Saturday, April 21, 2007

JAVA 認證心得 -- SCMAD (2)

CLDC 1.0/1.1

##CONTINUE##

  • Requirements by CLDC Sandbox model:

Ø Programmer can’t modify the class loading mechanism. Custom class-loading mechanisms are not allowed in CLDC.

Ø Classes must be verified to be valid by the CLDC pre-verifier and runtime verifier.

Ø Only a closed set of pre-defined profiles (like MIDP, WMA) are available to the programmer (you cannot use third-party libraries willy-nilly unless supported by the device!).

Ø Application programmer cannot write or use native code that is not part of the pre-defined packages (there is no Runtime.exec() method). Libraries containing native code cannot be downloaded into a device (unless it is a part of J2ME or that supplied by the device manufacturer).

  • WeakReference and Reference has been added to CLDC 1.1.
  • CLDC ensures application level security, which means a Java application can access only those libraries, system resources, and other componenets that the device and the Java application environment allows it to access. CLDC implementations is required to support Unicode characters, it means internationalization.
  • Exception Handling in CLDC

  • Event handling (low level or high level) is not in the scope of CLDC, It belongs to the profiles such as MIDP.
  • Both Runtime.gc() and System.gc() can be used in CLDC to persuade the Garbage Collector to reclaim unused memory.
  • Garbage Collector cannot be suspended or stopped manually.
  • The goal of a CLDC 1.1 specification

    Ø Smaller footprint

    Ø Dynamic downloading of applications

    Ø Focus on Application level programming

    Ø To remain as the “lowest common denominator” standard

  • CLDC supports the following four thread-safe collection classes

    Ø java.util.Vector

    Ø java.util.Stack

    Ø java.util.Hashtable

    Ø java.util.Enumeration (Interface)

  • When encountering any other error, the implementation should

    Ø Either halt the virtual machine in an implementation-specific manner.

    Ø Or throw an Error that is the nearest CLDC-Supported super class of the Error class that must be thrown according to the Java Language Specification

  • CLDC 1.1 requires that at least 32KB of volatile memory be available for the Virual Machine(VM) runtime and at least 160KB of non-volatile memory be available for the VM and CLDC libraries.
  • Presence of a minimal operating system or kernel to manage the hardware. Presence of one schedulable entity to run the virtual machine.
  • The default encoding is defined by the system property “microedition.encoding”
  • In CLDC 1.1, class java.lang.Math also includes support for trigonometric functions and square root calulation, and ceil and floor.
  • Any attempt to invoke finalize() method will result in a compilation error.
  • By default, the character property and case conversion facilities in CLDC assume the presence of ISO Latin-1 range of characters only. The implementations must provide support for character properties and case conversion for characters in the “Basic Latin” and “Latin-1 Supplement” blocks of Unicode 3.0
  • Class System

    - arraycopy(Object src, int src_position, Object dst, int dst_position, int length)

    - currentTimeMillis() , exit() , gc() , String getProperty(String key)

    - int identityHashCode(Object x)

  • String.intern()

    String.equalsIgnoreCase();

    Boolean.TRUE, Boolean.FALSE

    Date.toString()

    Random.nextInt(int i)

    Thread.interrupt();

  • Timezone in CLDC
  • CLDC performs a 2-step verification process. In the first step, which is called as preverification, the following processes take place

    Ø All the subrountines are inlined.

    Ø Special StackMap attributes are added into class files to facilitate runtime verification

    Ø Certain byte codes, which are irrelevant, are removed.

  • Since new attributes are added, a preprocessed file is approximately 10 to 15% larger than the orginal file.

Read more!

No comments: