all about JENE
by: Javaaah
156 of 156
Interesting thread ! I'd like to clarify a couple of points, and build an argument for why JENE is invaluable as
a Java enabler for embedded devices ...
Firstly, Sun's Java Embedded Server (or nanoserver) is NOT a Java virtual machine .. it is essentially a Java
application that runs on top of the virtual machine. Ditto JINI from Sun runs on top of a virtual machine.
**Crucial** : If the VM doesn't perform and fit the constraints of the embedded device (i.e; VM doesn't use
lots of memory), then both nanoserver and JINI have problems (ditto Java apps in general). Conversely if the
VM provides peformance and is small, then its a great marriage of technologies. So, what do we have in the
way of such technology for embedded devices, and what do they offer?? ...
Well, VMs are available from Sun (the "JDK" includes the VM), HP, Insignia, and others.
HP's is not state of the art. See their paper on Chai. The level of Java technology is supports is old. It is also
slow (see next paragraph).
Sun's VM was originally designed for the desktop, where memory and speed abound ... quite different from
an embedded device. Sun are having to get to grips with shoe horning it down to the embedded world, and
have no current solution for providing a performant VM on an embedded device (the usual way for making
Java run faster is to provide some form of compilation system, known as a "JIT" is Sun parlance. A JIT
converts Java applications (including those downloaded over the net)on the fly into the machine code for the
CPU on which the VM is running. A VM does not have to have a JIT, but as a bare minimum it must have an
"interpreter" which is SLOWWWW ...
-------------------
*** JITs are memory hungry, and don't fit nicely into the embedded world ***
--------------------
Sun's embedded VM, and HP's do NOT provide JITs. Companies that are Sun licencees will have ported
Sun's VM to their embedded platforms, and so are currently suffering the same problems. RTOS vendors are
typically Sun licencees also, and so, same problem!
To get over the performance issue, some companies are suggesting that Java applications for embedded
devices are "statically compiled" (i.e; converted to the appropriate machine code for the device's CPU)
upfront, and "burnt in" to the device. This strategy does NOT provide a performant solution to Java
applications which are delivered on the fly into a device (over some sort of network). You cannot convert up
front something you haven't seen yet!!!
Sun's nanoserver and JINI both essentially involve delivering Java on the fly to devices ... so static
compilation has problems in this scenario. If performance is required, and small memory usage is required,
then:
*** enter Insignia's JENE. ***
See Insignia's white paper ... JENE is a technology suite, which includes a configurable VM with low memory
footprint, and a ***dynamic compiler** which provides the performance boost that JITs provide in the
desktop environment. JENE is the only technology available to date that provides this. None of the other
VMs available for embedded devices has this functionality, and are a long way off, if you read their white
papers.
The Memorandum of understanding between Sun and Insignia would seem to imply that Sun are taking a
proactive view towards JENE. It seems to me that both companies could be of assistance to each other. If
Insignia gets Sun's blessing as a Java enabler, my guess is that Insignia has a very healthy future.
That's why I own Insignia stock!!!!!
Javaaah |
