Bill Sheppard wrote: >> Wilms wrote: >>You said the magic phrase 'well-defined'. I translate that to mean >>'restricted to'. Hence the assertion of 'run once debug everywhere' is >>correct. > > You might choose that translation, but it's not relevant. Java spans > from 8-bit microcontrollers to 64-bit CPU's. To expect the same > application to run across this breadth of hardware is neither realistic > nor useful. So what you're saying is that your kool-aid can't really be sold at all the lemonade stands. And it matters what glass you pour it into. Thanks for admitting that Java indeed can not run everywhere. That's a first! >>In terms of these platforms that a Java application is restricted to, >>will the same application that runs on a Nokia NGage run on a Siemens >>C55? Both use 'Java Technology' > > Many applications will. And were these phones compliant with more > recent industry-defined specifications, such as MIDP 2.0, a much larger > selection of applications would be compatible without specific debugging > effort. Well yes, but with restricted user experience, making it harder to charge that extra buck for the top of the line phone. Are you saying that MIDP2 requires no specific debugging, and that it will run on a 'specced' platform with zero test? Is that something Sun stands behind? I'm not discounting MIDP - Sun went after that and actually produced something good. >>http://www.comp.lancs.ac.uk/computing/users/fittond/ppcjava.html > And proves my point. The chart indicates VM's implementing more than > four completely different Java specifications targetting completely > different devices, plus VM's which have not passed any proper Java test > suite. MHP and OCAP have extensive test suites which all devices will > be required to pass; no ambiguity about what specification is being > implemented. This makes for a far more consistent environment for > developers. Of course, memory, CPU, graphics capabilities, and the like > will still vary from box to box, but the vast majority of OCAP > applications will run across all boxes with little-to-no debugging > across devices. Obviously you have not used some of the VM's on that list. To say some lack features and others have 'issues' would be an understatement. There is nothing consistent in the fact that there is a 'selection' of VMs. This development mode is more time consuming because one has to eval all the platforms, go through their documentation, have a test application to do speed comparisons, and then jump for one and hope there are no undefined bugs in the VM implementation. I'll stick to that C99, thanks. As for a spec to stick behind, remember when Java for STBs was called Personal Java, then J2ME, now J2ME fragmented into a family? http://java.sun.com/products/personaljava/index.jsp Those hardly ran a few years and then suddenly reached 'end of life'. I can only conclude that it must have been those pacman-clone demos running at 5fps on the JVM for STBs in NAB2000 that killed it. Cheers Kon ---------------------------------------------------------------------- You can UNSUBSCRIBE from the OpenDTV list in two ways: - Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line.