[opendtv] Re: OCAP - will it continue to move forward
- From: Bill Sheppard <Bill.Sheppard@xxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Fri, 15 Oct 2004 01:17:24 -0700
[Aargh! I don't know why Mozilla is munging the formatting]
Kon Wilms wrote: Bill Sheppard wrote: Wilms wrote: You said the magic phrase
'well-defined'. I translate that to mean 'restricted to'. Hence the
assertionof 'run once debug everywhere' is correct. You might choose that
translation, but it's not relevant. Java spans from 8-bit microcontrollers
to64-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
whatglass you pour it into. Of course it matters. If you served lemonade in
shot glasses you'd have very little repeat business.
Thanks for admitting that Java indeed can not run everywhere. That's a
first!The Java language can run (essentially) anywhere. Java platform
specifications are wisely targetted to be appropriate to the market for
whichthey are intended. It makes little sense to attempt to support J2EE
capabilities on a cell phone with 512K of memory and a 40 MHz processor.
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
compliantwith 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. Just as Doom
3 will only run satisfactorily on a high-end PC, there is certainly a class
of applications for which the mass-market phone may not be suitable.
Nonetheless, just as virtually any entry-level PC today is wholly sufficient
for the vast majority of everyday uses (i.e. email, browsing, word
processing, chat, etc.), most MIDP 2.0-based mobile phones will be
sufficientfor most applications.
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. Of course you can't claim no specific debugging and zero
testin all cases, but MIDP 2.0 added support for many of the areas which had
required proprietary vendor-specific API's in the past, such as sound.
Sun'sWireless Toolkit (WTK) is a PC-based implementation of MIDP which most
developers use as their development platform, and includes skins to emulate
various mobile phones. I believe you will find developers are very pleased
with this approach - in fact, it was selected as 2003 Development.com
Wireless Development Product of the Year.
Further assurance can be provided by JavaVerified.com. For a few hundred
dollars developers can submit an application to be certified across a range
of actual handsets, providing assurance to operators that applications will
execute properly across their installed base of phones. T-Mobile and Orange
recently announced they would require third-party applications to undergo
JavaVerified certification. This is a model which might be very appropriate
for the DTV market as well.
http://www.comp.lancs.ac.uk/computing/users/fittond/ppcjava.html[1] 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
thatC99, thanks. Rather than going through the process you outlined, the
"proper" method would be to select the appropriate Java specification for
thedevice (for a PocketPC that would likely be CDC/FP/PBP or PP), then
choosefrom among the implementations that are certified compliant to that
specification. Certification provides a high degree of confidence that
you'll not be impacted by bugs in the VM implementation. Most of the
products listed in that table come from "garage-shops" implementing
arbitrarycollections of Java API's (in violation of the copyright granted by
the Java language specification requiring all VM implementations to conform
to recognized specifications) and aren't suitable for production-quality
applications.
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[2] Those hardly ran a
fewyears and then suddenly reached 'end of life'. It's not nearly as dire as
you paint it. PersonalJava is the specification MHP and OCAP are based upon
(the bulk of the work having been done in 1998). It was superseded by the
J2ME architecture a few years later. J2ME introduced a much higher degree
ofmodularity, and includes the CLDC branch for small devices (i.e. cell
phones) and CDC for more capable devices (i.e. set-top boxes). MHP and OCAP
can be implemented on either PersonalJava or the CDC/FP/PBP stack;
applications can't tell the difference. New API's are added to J2ME all the
time to address new industry requirements (i.e. Bluetooth, XML, OpenGL,
etc.), but these all build upon either CLDC or CDC and don't obsolete the
existing specifications.
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. Both VM technology
andSTB capabilities have come a long way since then. And nothing's been
killed - MHP and OCAP are alive and well. You'll see.
-- -------------------------------------------------------------------------
Bill Sheppard Industry Marketing Manager bill.sheppard@xxxxxxx[3] Consumer
and Mobile Systems Group (408) 404-1254 (x68154) Sun Microsystems, Inc.
--- Links ---
1 http://www.comp.lancs.ac.uk/computing/users/fittond/ppcjava.html
2 http://java.sun.com/products/personaljava/index.jsp
3 mailto:bill.sheppard@xxxxxxx
----------------------------------------------------------------------
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.
Other related posts:
