Long live Kwai Chang Caine. On Tue, Feb 24, 2009 at 2:27 PM, Joshua Marinacci <[email protected]> wrote: > > Ancient Kung-fu Magic (tm) > > On Feb 24, 2009, at 9:19 AM, mbien wrote: > >> >> Hello, >> >> I am curious. JavaFX bytecode makes heavy use of annotations, many >> javafx RT classes also use enums and generics. How should this run on >> a 1.4 J2ME KVM? >> >> regards, >> >> michael >> >> >> On Feb 24, 5:41 am, Derek Munneke <[email protected]> wrote: >>> Just to make sure that everyone is on the same page, the JavaME >>> platformdoes not runon the theJava 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 packageThe >>> number of interfaces implemented by a classThe number of fields in >>> a classThe number of methods in a classThe number of elements in an >>> arrayThe number of bytes of code per methodThe length of a string >>> in a CONSTANT_UTF8 constant pool entryThe maximum amount of stack >>> that a method may useThe maximum number of locals that a method may >>> useStart-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 >> > > > > > >
-- Marcelo Morales --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
