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 > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
