Javaah: good analysis thanks. TurboJ does appear to be strictly an AHT, so ceding back the speed advantage of Insignia's JVM. Indeed, I can see that a combination of the two would not be out of place: perform the best AHT compilation when the device ships, but run the Insignia JVM to provide for field-upgradability with speed enhancement.
I do have serious concerns about the viability of true field-upgradability of Java applications, based on what I've seen of the incompatibilities so far between JDK 1.0, 1.1 and 1.2, Basically, once you pick a JDK and ship based on that, you either have to stick with it, or field-upgrade that too so your new code will run.
Coupled with a complete absence of version control mechanisms in Java I believe that field-upgradable internet appliances will remain a dream and not a reality in the near future. Until some company tackles that issue head on. Does Jini address that?
When you look at the whole Windows architecture mess, its weak point is DLL versioning, and most serious problems on the desktop occur right after field-upgrading an application from Microsoft, when they slipstream a whole new bunch of DLL's into your system, breaking other applications which depend on undocumented (and mostly unexpected) behaviour of the older DLL's.
That being the case: is field upgradability still a strong enough reason to choose the Insignia JENE JVM?
Also, (responding to your later post): while VxWorks is only one among many RTOS choices, it is by far the best IMO, and I believe will come to dominate the Internet Appliance market (I'm investing in WIND for that very reason). So, unless Insignia go down to the raw hardware and bypass an RTOS, aren't they are weakened by this announcement from WIND?
Comments?
P. |
