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