aaaaa00 said:
No, that is not how it works, the 10,000 methods claim (I saw the same MS FUD) is completely misleading. People who embed Java VMs don't implement the VM themselves or the core API (the majority of those 10,000 methods are in CORE packages like java.lang, java.io, etc, simialr to ANSI standard library)
There are few VM vendors on the market who produce VMs and implementations of the core API. In turn, the VM implementation and API implementation have to pass the Java TCK which ensures that the core APIs are correct.
The only thing that player vendors would have to implement is the org.bluray (and maybe the DVB/java.tv.*) packages which is the glue from the JavaVM to BR specific features. The rest of the code base cited above is portable and has no dependency on the player itself. The most likely scenario is to license the CDC HotSpot VM from Sun, or the J9 VM from IBM, or maybe Esmertec's. Get the PBP code from Sun. And the DVB/GEM code from an existing player, like MHP vendors.
This is the same as today with DVD. Most DVD firmware is outsourced. I happened to know the CEO of PlanetWeb (his wife is my wife's partner on the local tennis team), and they make the majority of firmware code that goes into those cheapo Chinese DVDs, from framebuffer management, menuing, MPEG-2 codec, etc. They also made the firmware in Sega DreamCast for web browsing.
BTW, isn't it interesting that HP has a big interest in Windows CE, and that initial versions of iHD are implemented with CE + .NET + JScript? How many methods and bugs are in Windows CE, .NET?
(carmack quotes deleted)
With all due respect, Carmack is very ignorant on the subject of the mobile space and many of his suggestions would be completely shot down by the operators of mobile networks. I've been working with mobile companies and operators since 2001, in fact, I sit on W3C and IETF working groups for mobile standards. Trying to get a mobile operator to even enable long-lived port 143 (IMAP) connections on mobile networks is an exercise in pain. Expert in 3D yes. Expert Experience in mobile? No.
Carmack's complaints about J2ME have nothing to really do with Java. He'd face the same problem with C. The fact is, mobile devices differ in input, differ by screen orientation, bit depth, differ by processor speed greatly. All of this greatly complicates any game of cross platform game development for mobile devices. For example, I can tell you right now, that if you write code for Motorola, Nokia, and Sanyo phones, you will get a different keycode value returned for the "select" button on the phone. That means you have to have 3 different branches for those three platforms. The Symbian, CE Smartphone, BREW, PalmOS, and Linux based phones different so much in how they deal with input, rendering, scheduling, allocation of processing power, that writing a cross platform phone app is a bitch in ANY language. Java actually solves many of the problems by interposing a layer between the OS and application, but it doesn't solve all problems, since the MIDP1.0 spec was flawed, that's why there is MIDP2.0.
That said, Carmack doesn't understand all the issues, because he just dabbles. There are MIDP2.0 applications on OMAP processor based phones which software render 3D using Java. The fact that a crippled processor phone with a interpreter based VM is so slow is not Java's fault, nor is the portability issue.
This is being solved in the mobile market data by trying to require minimal standards that all phones must adhere to, but getting manufacturers to restrict their innovation by agreeing to a lowest common denominator is hard.
For bluray, it is a completely different issue. BD doesn't have the form factor, input, and resolution issues that mobile phones do. They also won't have battery life and processing speed to contain with, which are big constraints.
This is not true. HDMV has significant functionality over DVD Menuing, and the programmability is alot fuller.
Care to list iHD specifics, API calls, XML tag types, that can't be done in HDMV?
Last edited by a moderator:
