[The Java Posse] Re: Java ME vs. Java 5

Mon, 23 Feb 2009 20:41:51 -0800


Just to make sure that everyone is on the same page, the JavaME platform does not run on the the Java Virtual Machine, unlike JavaSE, JavaEE (or JRuby, Jython, Scala, etc..)

JavaME applications run on a "K Virtual Machine" ('K' for KB (40-80KB in size!), or cause it comes after the letter 'J'); this runtime environment does not confirm to the JVM specification.

Areas where a KVM differ from the JVM <http://java.sun.com/products/cldc/wp/#spec>
  • Large data types: long, float, and double -- many configurations do not need the extended range and precision of the larger data types.
  • Multi-dimension arrays -- many configurations do not need to support arrays of more that one dimension.
  • Class file verification -- some specified configurations may not need to support on-device verification of class files. Instead technology is planned to be developed to enable class files to be efficiently verified "off-line" and delivered to the device.
  • Handling of Error classes -- when the Java virtual machine encounters a serious internal problem, it throws an instance of a subclass of java.lang.Error. However, because there is often no reasonable form of programmatic recovery from these errors, a configuration may specify the KVM to halt with a configuration-defined error indication. Or the configuration may allow device vendors to define device-specific behavior and recovery actions when it encounters such conditions.
  • Threads and event handling -- some configurations may require a different application execution model from the standard Java technology-based model using the Thread class and standard event handling.
  • Java Native Interface (JNI) -- many configurations might not need the flexibility of the JNI for the way in which native methods are linked and invoked. A configuration may use a defined alternative, simpler mechanism to invoke native methods.
  • Class loaders -- many configurations might not need the full flexibility of Java class loaders. A configuration must specify the mechanisms by which classes are located and loaded into the KVM.
  • Finalization -- many configurations do not need to support object finalization.
  • Maximum size limitations -- many configurations do not need to support the full range of sizes of internal virtual machine data structures. A configuration may specify a "maximum supported" range for some or all of the following values:
    • The number of classes in a package
    • The number of interfaces implemented by a class
    • The number of fields in a class
    • The number of methods in a class
    • The number of elements in an array
    • The number of bytes of code per method
    • The length of a string in a CONSTANT_UTF8 constant pool entry
    • The maximum amount of stack that a method may use
    • The maximum number of locals that a method may use
  • Start-up -- each configuration must specify how the KVM locates the initial class and method to execute and the expected attributes of that class and method.


    • Another thing of note, on a phone you can't just install your KVM of chose since the platforms are mostly closed; so you are stuck with what ever the device vendor provides, expect on "smart phones" that provide an Open OS that allow binaries to be ported and loaded [1] ; does this mean the iPhone is not a smart phone?

    This also means there are at least a dozen main KVM's in use, and many more, so unlike in the desktop world where you can specify a JVM your product will work on, in the mobile world you have to program for all of the KVM quirks (as well as devices differences like screen size, graphics offsets, input methods, and hardware services).

    And as Jess mentioned, this also means that when/if a new KVM version is released, the users cannot just install the update; so we are stuck with what we have got if we want to reach any kind of majority of the 4 billion mobile phone subscribers.

    /derek

    [1] my definition of a smart phone.

    Alex Buckley wrote: 
    On Feb 17, 7:47 am, Brian Frank <[email protected]> wrote:
  
    The Java modularity work has changed directions a couple times, so I
am not completely sure what the current design is.  But I think it can
go a long way to the solve the J2ME problem if the following holds
true:
    
1. The "kernel" is similar in size and scope to what J2ME is today

2. The modularity is granular enough that big subsystems like AWT,
Swing, and CORBA don't get sucked in because you wanted something from
NIO (just a silly example, but there are some weird package inter-
dependencies)

3. A suitable licensing model is provided such that you don't have to
ship a device with every J2SE module.
    
    
You are basically describing the JRE/JDK modularization story that
Mark told at Devoxx: http://tinyurl.com/cm5qmy :-)

The Jigsaw module system has a bunch of features to support profiles;
subsetting and refactoring of the SE APIs; and (perhaps) feature-based
provider selection ("give me a module with MP3 and Ogg support").

Alex


    --~--~---------~--~----~------------~-------~--~----~
    You received this message because you are subscribed to the Google Groups "The Java Posse" group.
    To post to this group, send email to [email protected]
    To unsubscribe from this group, send email to [email protected]
    For more options, visit this group at http://groups.google.com/group/javaposse?hl=en
    -~----------~----~----~----~------~----~------~--~---

    Reply via email to