The Insider's Thread has had some recent back and forth regarding growing pains on the two platforms. Some of it has revolved around the performance of the interactive subsystems (BD-J and HDi). This has been the subject of some debate a while back, but now we have a couple of generations of hardware, and some time to have ascended the learning curve of authoring somewhat.

Given that the Insider's thread is not a place for general comment, I thought we might be able to get some discussion here. The intention is to disc what issues either platform may have as a result of a short-term growing pain type of scenario, or if it may be an architectural issue endemic to the format spec.

Talkstr8t made this comment in regard to some of the BD-J performance problems, when explaining why he believed that there would not be responsiveness issues on the whole:

I've never heard someone complain about the speed of their Blackberry, yet that's an all-Java device (even the OS) running on a relatively modest CPU."

Talk, you could NOT have picked a worse example for me. I've been carrying a Blackberry for upwards for a couple of years now, over 2 or 3 OS revisions, and the OS/App suite blows. It's slow (how about MOST of a phone number dialed before the interface catches up?), locks up, and generally not nearly responsive enough for the HUI feedback necessary for a personal device.

I've had WinCE, Palm and dedicated phone OS's on devices several generations older/less powerful, and I've preferred the "feel" and responsiveness of every one of them over my BB. Incidentally, the other 8 members of my team have similar experiences, and there are a few different hardware models in there. And I've purposely opted to NOT load any additional software on the unit, simply to avoid exacerbating the problem.

While I don't want this to become a general Java-bash, I'll say that even with JIT compilers, multiple SUN Java updates, etc, I've found that most of the time the performance of a Java based environment significantly degraded as compared to a native solution on my desktops.

For example, I have a Java web-photo app I use because of the feature set, but I only do so DESPITE being Java based. It's easily 3-4 times slower performing operations similar to other native apps. Using GoToMtg's remote-control Java applet is painful compared to native VNC or Remote Desktop. As a more direct comparison: the Java VNC client sucks compared to it's own native sibling. (And yes, this is all on reasonably capable hardware).

I could go on, but suffice it to say that while I'm sure 2+ minute load times for PoTC is simply an anomaly that content authors will be able to address, I'm not sure I'll ever really expect "snappy response" from a BD-J based environment....

Using a crackberry for work can be downright frustrating sometimes...

Lag lag lag pause lag pause...

Some say it's all in the coding, but it also depends on the language base you begin with...

You can find poorly written programs in any language. Have you worked with any .NET applications lately? Talk about slow startup times.

Anyway, your remote desktop Java client may be slow (I've had good luck with the Java VNC client) but I'd wager it would be impossible to implement using the technologies behind HDi.

People would be surprised to learn how frequently they use Java. Everything from electronic trading to online shopping would come to a screeching halt without it.

People would be surprised to learn how frequently they use Java. Everything from electronic trading to online shopping would come to a screeching halt without it.
Frequency of use has nothing to do with performance, just because it's used all over the place doesn't make it good.

And then there's the "New CA" aka Sun.

Getting back to the original subject, growing pains are to be expected. That's why Toshiba put out FW updates. I expect some on the BD side as well. Both sides had/will have a few hiccups and glitches. That's just life on the bleeding edge.
J

Frequency of use has nothing to do with performance, just because it's used all over the place doesn't make it good.

And then there's the "New CA" aka Sun.


Interesting comment considering the "good enough" mentality around here.

Other languages are faster. But that's not the reason Java is chosen over and over for all sorts of applications. Some people get it, some don't. Even Microsoft with their Java clone (C#) understands.

Interesting comment considering the "good enough" mentality around here.

Other languages are faster. But that's not the reason Java is chosen over and over for all sorts of applications. Some people get it, some don't. Even Microsoft with their Java clone (C#) understands.
You can tout whatever lines your pockets (we all gotta make a living :D ) all you'd like but the OP's comments are not an uncommon experience - on any most any platform.

Get a room full of engineers & often you'll find that the oft touted "compile once & run everywhere" is often followed by laughter & it really means "compile once & just maybe it'll run somewhere".

Personally I have serious doubts about using it for the interactive features for BD, same experiences as the OP (with differing devices). If it were an application with zero changes expected through the lifecycle......maybe......constant updates? Asking for glitches.

Personally I have serious doubts about using it for the interactive features for BD, same experiences as the OP (with differing devices). If it were an application with zero changes expected through the lifecycle......maybe......constant updates? Asking for glitches.

Bah, I've been working extensively in Java for ten years now, back end, AWT, Swing, web apps, etc. across many platforms and devices. I haven't encountered any cross-platform inconsistencies for years.

Java, even mobile edition, has been around for many years and shipped on millions of devices. It's been used and tested a lot more than HDi has.

For any slow Java device story you throw out, I can give you a slow/buggy PocketPC, Windows ATM, or Ultimate TV story to match it. Enough with the platform generalizations already.

Get a room full of engineers & often you'll find that the oft touted "compile once & run everywhere" is often followed by laughter & it really means "compile once & just maybe it'll run somewhere".
.

I work QA for a Java app that runs on 2k/XP/Vista and about 7 distros of UNIX... I about spit soda laughing at that comment :D

SO true.

Enough with the platform generalizations already.
Why? That's the point of this thread, to discuss potential growing pains with the BD-J implementation on BD devices. Since it's not on any current models the only reference is other platforms.

My opinion, based on experience, is that for fixed version devices it can work well - I question the glitches that may occur in a constant upgrade device like a BD player.

I work QA for a Java app that runs on 2k/XP/Vista and about 7 distros of UNIX... I about spit soda laughing at that comment :D

If A Java program doesn't run well on those platforms (btw. what is a UNIX distribution?) doesn't mean the problem is in the technology. Bad developers produce bad software, technology doesn't help there. There are numerous Java programs which run as well on any platform (Azureus, JEdit, JAlbum, Netbeans, etc.). If developers know their tools and technologies Java is very good and easy way to implement platform independent software.

Current mobile phones (pretty cheap ones even) run Java programs very well. Performance shouldn't be a problem at all. Java is really good choice for Blu-ray. In an embedded environment like a Blu-ray-player most of the VM can always be "running" thus cutting down startup times considerably. I've never seen 2+ minutes load times with POTC with PS3 :)

You can tout whatever lines your pockets (we all gotta make a living :D ) all you'd like but the OP's comments are not an uncommon experience - on any most any platform.

Get a room full of engineers & often you'll find that the oft touted "compile once & run everywhere" is often followed by laughter & it really means "compile once & just maybe it'll run somewhere".



I don't have those problems. Perhaps those engineers you know should go back to school. It's not 1997. Things have changed.

I work QA for a Java app that runs on 2k/XP/Vista and about 7 distros of UNIX... I about spit soda laughing at that comment :D

SO true.


Are you saying you'd have less work to do if you worked QA on a C++ app that ran on Windows and seven distros of Linux? (HINT: Your product would never ship).

If A Java program doesn't run well on those platforms (btw. what is a UNIX distribution?) doesn't mean the problem is in the technology. Bad developers produce bad software, technology doesn't help there. There are numerous Java programs which run as well on any platform (Azureus, JEdit, JAlbum, Netbeans, etc.). If developers know their tools and technologies Java is very good and easy way to implement platform independent software.

Current mobile phones (pretty cheap ones even) run Java programs very well. Performance shouldn't be a problem at all. Java is really good choice for Blu-ray. In an embedded environment like a Blu-ray-player most of the VM can always be "running" thus cutting down startup times considerably. I've never seen 2+ minutes load times with POTC with PS3 :)

:rolleyes: you know what I meant...

Point is I run QA on a variety of VCO's. Consistency is what I measure. If it was 100% consistent all the time, there wouldn't be a need for me. End of story.

Are you saying you'd have less work to do if you worked QA on a C++ app that ran on Windows and seven distros of Linux? (HINT: Your product would never ship).

I didn't 'say', and didn't even mention C++. I'm well aware of the benefits of Java. I'm also aware of how it likes to behave differently at times.

You can find poorly written programs in any language. Have you worked with any .NET applications lately? Talk about slow startup times.

Anyway, your remote desktop Java client may be slow (I've had good luck with the Java VNC client) but I'd wager it would be impossible to implement using the technologies behind HDi.

People would be surprised to learn how frequently they use Java. Everything from electronic trading to online shopping would come to a screeching halt without it.

Actually, I'm involved in a startup that is writing an interface in .NET. While there can be some startup delay to load in the .NET interface libraries and the assemblies, the system resposiveness once loaded is no different than "native" in my experience. I've installed quite a few apps that need either .NET 1.1 or 2.0, and haven't had nearly the same experience I have as those using JRE.

Whilst I know Java is widely in use, I'm not convinced it's a great fit in some of them.

Getting back to the original subject, growing pains are to be expected. That's why Toshiba put out FW updates. I expect some on the BD side as well. Both sides had/will have a few hiccups and glitches. That's just life on the bleeding edge.
J

Agreed. And I think things like individual titles not playing, a menu item misbehaving, etc... are indeed to be expected.

What I'm not convinced of, is the selection of Java as an interpreted environment being something that's in individual glitch as much as a poor architectural choice for the platform. Using Talkstr8t's example of Blackberry's using Java is a perfect example... the interface blows.

I know it's similar to GEM/OCAP, and I honestly don't know what set-top boxes use that environment... but I DO know that my Dish 622, and my buddies TiVO's are quite responsive, and they are Linux based with a custom GUI. Until I load the interactive channel that is.. and then it's like wading thru molasses.... anybody know what that environment is? I suspect much of that latency may be due to waiting on the satellite data delivery....

Interesting comment considering the "good enough" mentality around here.

Other languages are faster. But that's not the reason Java is chosen over and over for all sorts of applications. Some people get it, some don't. Even Microsoft with their Java clone (C#) understands.

It's certainly likely that with differing underlying architectures for the CE devices, that Java's "Write once debug run anywhere" promise was a big influence.

It's just a simple reality that there is a cost (in terms of complexity, performance, and compatibility, that comes with such solutions (C# included), and those tradeoffs may not be worth it in all situations. Embedded electronics may be one of them.

Bah, I've been working extensively in Java for ten years now, back end, AWT, Swing, web apps, etc. across many platforms and devices. I haven't encountered any cross-platform inconsistencies for years.

Really? Wow. I've read enough app notes with version dependencies on JUST the Sun JRE that makes me think you've been extremely fortunate.

Java, even mobile edition, has been around for many years and shipped on millions of devices. It's been used and tested a lot more than HDi has.

For any slow Java device story you throw out, I can give you a slow/buggy PocketPC, Windows ATM, or Ultimate TV story to match it. Enough with the platform generalizations already.

There are certainly bad implementations of {insert_platform_here} to be found. But I was using Talkstr8t's example of the Blackberry as a very SPECIFIC case. I've used several differing generations and models, and the interface blows from a responsiveness/usability standpoint.

And I'll certainly cop to it being a generalization, but for me it's held true that a majority of the time, the VM layer of PC-based Java environments introduces a level overhead that reduces the responsiveness of the system as well.

I've seldom heard somebody that feels that this overhead is non-existent, and I question weather this is "a good thing" on systems running with significantly constrained hardware resources.

I downloaded a .NET app that was simple front-end to a command-line application. The startup time was horrendous. I'm tempted to write a Java version.

Would I write the next Photoshop in Java? Uh, no but at least it would be possible. Something I doubt could be accomplished with HDi's underlying technology.

.NET isn't necessarily a bad proposition - if you're running Windows (and your company has lots of cash to pay for things that are typically open source in the Java world).

Really? Wow. I've read enough app notes with version dependencies on JUST the Sun JRE that makes me think you've been extremely fortunate.



There are certainly bad implementations of {insert_platform_here} to be found. But I was using Talkstr8t's example of the Blackberry as a very SPECIFIC case. I've used several differing generations and models, and the interface blows from a responsiveness/usability standpoint.

And I'll certainly cop to it being a generalization, but for me it's held true that a majority of the time, the VM layer of PC-based Java environments introduces a level overhead that reduces the responsiveness of the system as well.

I've seldom heard somebody that feels that this overhead is non-existent, and I question weather this is "a good thing" on systems running with significantly constrained hardware resources.


Unless you want a unified architecture across all players, virtual machine technology (whether Java or something else) is the only sensible answer. All VMs have a performance penalty - that's the price you pay for portability and security.

If A Java program doesn't run well on those platforms (btw. what is a UNIX distribution?) doesn't mean the problem is in the technology. Bad developers produce bad software, technology doesn't help there. There are numerous Java programs which run as well on any platform (Azureus, JEdit, JAlbum, Netbeans, etc.). If developers know their tools and technologies Java is very good and easy way to implement platform independent software.

Current mobile phones (pretty cheap ones even) run Java programs very well. Performance shouldn't be a problem at all. Java is really good choice for Blu-ray. In an embedded environment like a Blu-ray-player most of the VM can always be "running" thus cutting down startup times considerably. I've never seen 2+ minutes load times with POTC with PS3 :)

Jalbum is the app which I was referring to in my original post. I've run it on probably half a dozen differing configurations of hardware, and it consistently makes me feel like I've cut the resources in half. When you have a fast Intel Core Duo, it doesn't really matter. On a P4-1.6Ghz, it becomes painful in some cases, whereas native apps on the same machine don't introduce that kind of latency.

Your final comment is a very cogent point: Sony's "Supercomputer as a game console" runs the code fine... Sony's $1000 BR player takes 2 minutes to load the game, and then has severe usability issues once running. That is one of the concerns.

Unless you want a unified architecture across all players, virtual machine technology (whether Java or something else) is the only sensible answer. All VMs have a performance penalty - that's the price you pay for portability and security.

Not necessarily. Do you have Intel and Sparc versions of your HTML code? ;)

This is what HDi's XML-style declarative structure addresses: cross platform capability without VM overhead.

I downloaded a .NET app that was simple front-end to a command-line application. The startup time was horrendous. I'm tempted to write a Java version.

Would I write the next Photoshop in Java? Uh, no but at least it would be possible. Something I doubt could be accomplished with HDi's underlying technology.

.NET isn't necessarily a bad proposition - if you're running Windows (and your company has lots of cash to pay for things that are typically open source in the Java world).

I think getting too far off base in discussin .NET would likely not be helpful here, because that's not really in use in either environment. I was probably in error in even responding to the .NET comment above.

It's really more a question of the approaches embodied by a VM versus a parsing/rendering engine that HDi uses.

Your Photoshop example is a good one... I think it illustrates the selection of the appropriate technology for a given environment and application. If the overhead associated with the VM is significant enough that you wouldn't want to try something significantly complex, then you are limited anyway. If that's the case, why not avoid the VM overhead for EVERYTHING that must run, and instead provide a focused environment that runs everything within the scope well?

Given the contrained environemnt for which these apps will run, it's not an insignificant question.

Why? That's the point of this thread, to discuss potential growing pains with the BD-J implementation on BD devices. Since it's not on any current models the only reference is other platforms.

The topic of this thread was performance... you seem to have introduced platform updates as a non-sequitur.

BD-J is shipping in current Blu-Ray players. Maybe you misunderstand this.

My opinion, based on experience, is that for fixed version devices it can work well - I question the glitches that may occur in a constant upgrade device like a BD player.

Java is no more vulnerable on updated platforms than most other technologies raised in this thread. If it's being interpreted, it's got a runtime between it and the other hardware and software layers that can insulate it from changes.

As always, testing and abiding by API contracts is key, no matter the platform.

Bah, I've been working extensively in Java for ten years now, back end, AWT, Swing, web apps, etc. across many platforms and devices. I haven't encountered any cross-platform inconsistencies for years.

I'm surprised to read that. My experience shows that there are differences/inconsistencies even in virtual machines for the same platform (e.g. Suns JRE for Windows and IBMs JRE for Windows) causing trouble, not to mention VMs for different platforms. Graphic applications based on AWT and SWING cause headache sometimes, but also very basic things like when the garbage collector is started, if any, or threading issues.

I don't want to go too much into detail here. To give everyone an idea I recommend to feed the Google search engine with "Java platform inconsistencies", which brings up 500,000 hits to the topic.

I can only speak from my own experience, but I wouldn't touch java with a 10 foot pole. I used to develop primarily in java, but there is a point where its complexity doesn't match its functionality (not to mention performance). Java was supposed to be the be-all-end-all universal platform, and lets face it, it didn't happen. As tteich said, there are a bunch of inconsistencies which completely kill the "code once, run anywhere" slogan.

Native code will always run faster than a VM. There is no question there. Scripting/markup languages like XML, are where the real future of the internet is. Java died a long time ago as far as I'm concerned. Just look at all the popular sites on the internet, how many of them are still using Java? But I bet they are using XML, DHTML and other scripting languages more related to the HDi implementation. There are a couple of popular programs that use Java (Azereus being one), but the vast majority of apps are written using native code. And they are faster and more reliable because of it. Java works for some applications under certain circumstances, but if I can avoid using it, I will. It is much better to have a native interface which is light and solid, than a robust platform that works on everything, but optimized for nothing.

+1 for cybereality's post. I cringe when I find out an app is in Java. Nuff said.

Does Java have a position on porn? ( :D )

Native code will always run faster than a VM.
...
Scripting/markup languages like XML, are where the real future of the internet is.
...
It is much better to have a native interface which is light and solid, than a robust platform that works on everything, but optimized for nothing.
You realize that scripting languages aren't native code, right?
And that popular Ajax web apps (like Gmail) aren't native interfaces?

There's nothing wrong with having an opinion against Java or any other tech (I personally hate Flash), but there is a lot of misinformation in this thread.

I'm surprised to read that. My experience shows that there are differences/inconsistencies even in virtual machines for the same platform (e.g. Suns JRE for Windows and IBMs JRE for Windows) causing trouble, not to mention VMs for different platforms.
There are many, many more difficult inconsistencies coding across different browsers (Firefox, Mozilla, etc.) on the same platform than coding across JVMs on the same platform. But web apps continue to thrive, too.
I don't want to go too much into detail here. To give everyone an idea I recommend to feed the Google search engine with "Java platform inconsistencies", which brings up 500,000 hits to the topic.
Ummm... Did you even scan those links? Most of them have nothing to do with inconsistencies in the Java platform, but inconsistencies in data or documentation in the same document as a reference to Java.

And I just did a Google search for ".Net platform inconsistencies" and got 1,300,000 results. Clearly .Net is twice as inconsistent, even though it only runs on one platform!

We get it. Lots of HD DVD fans on this forum don't like Java. Which is good because they won't be forced to suffer through the more powerful apps it allows developers to build.

You realize that scripting languages aren't native code, right?
And that popular Ajax web apps (like Gmail) aren't native interfaces?

There's nothing wrong with having an opinion against Java or any other tech (I personally hate Flash), but there is a lot of misinformation in this thread.

Neither is C.

You are mixing paradigms here. Nothing other than "machine instructions" are technically "native" to a given CPU architecture.

Languages, including some scripting languages incidentally, can either be interpreted or compiled. They then can run either "native" (in this context it's running directly "on" the hardware, and is hence CPU architecture specific), or in a Virtual Machine, which abstracts the hardware architecture.

Things such as Just In Time(JIT) compilers blur this line slightly, but nonetheless a scripting language executed directly by it's interpreter is considered a native execution environment, not a virtualized one.

There are many, many more difficult inconsistencies coding across different browsers (Firefox, Mozilla, etc.) on the same platform than coding across JVMs on the same platform. But web apps continue to thrive, too.

Ummm... Did you even scan those links? Most of them have nothing to do with inconsistencies in the Java platform, but inconsistencies in data or documentation in the same document as a reference to Java.

And I just did a Google search for ".Net platform inconsistencies" and got 1,300,000 results. Clearly .Net is twice as inconsistent, even though it only runs on one platform!

We get it. Lots of HD DVD fans on this forum don't like Java. Which is good because they won't be forced to suffer through the more powerful apps it allows developers to build.


Believe me, my distaste for Java predates the HD wars.

Incidentally, my OP had nothing to do with being Pro HD DVD. It had to do with being concerned that Talkstr8t is holding up a Blackberry as an ideal of a java execution environment...

Not necessarily. Do you have Intel and Sparc versions of your HTML code? ;)

This is what HDi's XML-style declarative structure addresses: cross platform capability without VM overhead.


Yes - with GREATLY diminished capabilities. I wrote a very well-received emulator of an old 8-bit platform in Java. Something like that would be impossible in HDi, Javascript, VBScript or other markup language.

Yes - with GREATLY diminished capabilities. I wrote a very well-received emulator of an old 8-bit platform in Java. Something like that would be impossible in HDi, Javascript, VBScript or other markup language.

Are you simply ignoring parts of this?

You said that VM's were the only sensible answer for cross-architecture capability. Clearly that isn't the case, as illustrated with HTML, etc...

The issue if scope certainly come with tradeoffs as well. A more focused environment that executes faster/more consistently rather than one that is saddled with significant overhead so far seems to have delivered well on the HD formats.

This reminds me of this article about the pains of deploying Java on mobile phones (http://news.com.com/Write+once,+run+anywhere+not+working+for+phones/2100-1037_3-5788766.html). Will we be seeing the same fragmentation effect in BD? :confused:

I take it you don't use E-Bay, trade stocks on NASDAQ or do any sort of online banking? You probably don't have a Blu-Ray player either or a Nokia phone.

Interestingly, I cringe when I discover how clueless people are...

Nuff said.

I assume you are speaking of Java Server Pages? Bit of a different beast here...

I have owned a BluRay player, although there are few enough titles that use BD-J extensively enough to do much of an evaluation. Not sure why you'd be citing that as an example... there have actually been some severe inconsistencies reported.

No Nokia phone, but I have used them.

Are you simply ignoring parts of this?

You said that VM's were the only sensible answer for cross-architecture capability. Clearly that isn't the case, as illustrated with HTML, etc...

The issue if scope certainly come with tradeoffs as well. A more focused environment that executes faster/more consistently rather than one that is saddled with significant overhead so far seems to have delivered well on the HD formats.

A VM is the only option if you want security, portability and power beyond simple scripting and markup.

By the way, CPUs (including embedded processors) are growing more powerful. A few of the early players were severely underpowered IMO. It's best to be forward thinking when it comes to technology. That's why 50GB will always be better than 30.

I assume you are speaking of Java Server Pages? Bit of a different beast here...

I have owned a BluRay player, although there are few enough titles that use BD-J extensively enough to do much of an evaluation. Not sure why you'd be citing that as an example... there have actually been some severe inconsistencies reported.

No Nokia phone, but I have used them.


Many of the anti-Java comments in this thread are focused on Swing apps - a completely different beast than BD-Java (and yet apparently relevant to the topic). JSPs and servlets are excellent examples of Java in action.

Java isn't the most popular programming language on the planet because Sun Microsystems runs a monopoly...that would be the other company.

You realize that scripting languages aren't native code, right?
And that popular Ajax web apps (like Gmail) aren't native interfaces?Yeah, I do. I was making different points, but it kinda got mixed up.

The point was about the major difference in abstracting the data from the code by use of markup languages. Its about data-driven design, and that is where the future is. Not with Java, which honestly had its day and should be forgotten. I know they use Java on a lot of cell phones. And guess what? Those cell phone apps are clunky as hell. The games don't even match the Genesis. Maybe java has something to do with it.

There are many, many more difficult inconsistencies coding across different browsers (Firefox, Mozilla, etc.) on the same platform than coding across JVMs on the same platform. But web apps continue to thrive, too.

Ummm... Did you even scan those links? Most of them have nothing to do with inconsistencies in the Java platform, but inconsistencies in data or documentation in the same document as a reference to Java.

And I just did a Google search for ".Net platform inconsistencies" and got 1,300,000 results. Clearly .Net is twice as inconsistent, even though it only runs on one platform!

We get it. Lots of HD DVD fans on this forum don't like Java. Which is good because they won't be forced to suffer through the more powerful apps it allows developers to build.
Yes, I scanned those links. You are right, probably more than 50% of them don't address platform incompatibility issues, but others link to bug reports, and all kinds of problems which address exactly what I was trying to say with my post. Here are some examples:
http://nostalgia.wikipedia.org/wiki/Java_programming_language (for the general public, search the text for the word "inconsistency")
http://www.eweek.com/article2/0,1895,873887,00.asp (this is an interesting article from 2003 where software engineers from SUN - the inventor of Java - criticize their own JRE for their own Solaris operating system, for several reasons)
http://mindprod.com/jgloss/gotchas.html (interesting read for every Java programmer by the way)

Not offending, but I cannot buy your statement after "working extensively in Java for ten years now..." you "haven't encountered any cross-platform inconsistencies for years". This does not match the daily reality of a software engineer who is doing in Java.

For the record, I like Java as a concept and as a programming language. I hate it for its implementation(s), and for their (still) poor performance.

As you counter my argument with .NET: I don't think HDi is based on .NET. As far as I understand is HDi an XML based media description "language". From a stability, maintenance, servicability point of view, a specialized language (like HDi, or just the DVD menu description to take a simple example) better suits the needs of applications with well defined use cases.

A general purpose language (like Java) gives you a lot of flexibility, but adds costs and time for architecture, specification, implementation and test of the runtime system, implementation and test of the applications, documentation.

I don't know HDi from inside out, but the fact that it was developed with Studio participation (e.g. Disney) makes me believe it fits studio requirements, and customer needs.

Even though I think this discussion has not much to do with BD-J anymore I must comment on this. We were discussing about platform inconsistency.

http://nostalgia.wikipedia.org/wiki/Java_programming_language (for the general public, search the text for the word "inconsistency")
In this old article there's a mention of some platform inconsistencies. However, current wikipedia article doesn't mention any platform inconsistencies.


http://www.eweek.com/article2/0,1895,873887,00.asp Once again an article from 4,5 years ago doesn't really prove that you can't say "haven't encountered any cross-platform inconsistencies for years".

http://mindprod.com/jgloss/gotchas.html (interesting read for every Java programmer by the way)True, interesting to read, but has nothing to do with platform inconsistency.

Many people base their opinions on Java on situation years ago. Java platform has gone through some massive changes in last few years. Since version 1.4 it has performed extremely well on the server side. Latest version 6 started the same change on the GUI side. The upcoming version 7 will improve startup speed of GUI applications a lot.

When it comes to BD-J it has nothing to do with GUI apps being slower. BD-J is more like the mobile edition of Java which doesn't have AWT or Swing. Even with very slow processors J2ME runs pretty well on mobile phones. For example some Google's J2ME apps (GMail) are very well done and run fast.

When it comes to the bug of POTC loading slowly on some players, I thought that was already fixed with firmware updates. So that hardly can be a proof of BD-J being slow.

This reminds me of this article about the pains of deploying Java on mobile phones (http://news.com.com/Write+once,+run+anywhere+not+working+for+phones/2100-1037_3-5788766.html). Will we be seeing the same fragmentation effect in BD? :confused:

A quote from the article:

"Defragmentation remains a major issue," Nokia Chief Technology Officer Pertti Korhonen said during a recent speech to Java developers. "We need to reduce the fragmentation effect because interoperability is critical for today's mass market devices. We need to simplify the standard, and use open, fair and predictable licensing terms for the technology."

The fact is that Nokias Symbian (S603rd edition in particular) is much much better than Java based programs. S603rd is much more stabile, compatible and faster.

That said, though, I don't know if all this has anything to do with Blu-ray's implementation of Java.

I can't reveal internal information from my company so I tried to find arguments which are available for the general public, like those articles. Been involved in Java activities for embedded systems, my experience shows that you can omit platform inconsistencies if you use one and exactly one Virtual Machine implementation and port this to the different platforms, instead of taking VM from company A for one system and VM from company B for the second, and so on. This makes things easier, but does not solve all problems which typically occur in such environments.

The example which abbiyr has found reflects the reality pretty well:

This reminds me of this article about the pains of deploying Java on mobile phones (http://news.com.com/Write+once,+run+anywhere+not+working+for+phones/2100-1037_3-5788766.html). Will we be seeing the same fragmentation effect in BD? :confused:
So at this point I will stop arguing further. Time will tell how the java approach pans out.

The topic of this thread was performance... you seem to have introduced platform updates as a non-sequitur.

BD-J is shipping in current Blu-Ray players. Maybe you misunderstand this.
.
You're right, I thought the thread was primarily about the interactive features.

I don't have those problems. Perhaps those engineers you know should go back to school. It's not 1997. Things have changed.
Heeeyuck - that's so funny. Toss whatever manure you like, song remains the same.

I take it you don't use E-Bay, trade stocks on NASDAQ or do any sort of online banking? You probably don't have a Blu-Ray player either or a Nokia phone.

Interestingly, I cringe when I discover how clueless people are...

Nuff said.
So do a lot of other people judging by the thread. Widespread does not mean it's either good or fast - i.e. Windows.

When it comes to the bug of POTC loading slowly on some players, I thought that was already fixed with firmware updates. So that hardly can be a proof of BD-J being slow.
Which brings up one of the major points - how are updates going to proceed? Internet? On machines that don't have a connection mandated? Discs mailed to customers? Sony has historically not been much for updating (PS3 aside) CE devices. Or will it be on the discs? If it's the last choice I see major issues. Various platforms using the same code as updates? Or will it have versions for every machine on the market? This could be real problematic - ending up with VM vs update mis-matches, historically a JAVA weakpoint.

Java isn't the most popular programming language on the planet because Sun Microsystems runs a monopoly...that would be the other company.
Really, we should leave "The new CA" out of the discussion.

Current mobile phones (pretty cheap ones even) run Java programs very well. Performance shouldn't be a problem at all. Java is really good choice for Blu-ray. In an embedded environment like a Blu-ray-player most of the VM can always be "running" thus cutting down startup times considerably. I've never seen 2+ minutes load times with POTC with PS3 :)
Define "very well" - number one complaint I've heard with most cell phones is speed. From boot time to app response - it's tooooo sslllloooooooow. Given that the PS3 will likely be a bit player in the BD market (theory, standalones dominate) what does that mean for overall BD player performance?

The point was about the major difference in abstracting the data from the code by use of markup languages. Its about data-driven design, and that is where the future is.
Exactly, data driven - an arena where XML(ish) is ideal. I'd imagine the interactive functions of the players to be very much data driven.

So at this point I will stop arguing further. Time will tell how the java approach pans out.
Yep, only time will tell & my position is that based on experience & historical performance I view the use of JAVA as the single biggest knock against the BD platform.

Here's an interesting article to help combat the rampant FUD in this thread:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

An excerpt:

"Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled).

Nevertheless, the idea that "java is slow" is widely believed. Why this is so is perhaps the most interesting aspect of this article."

By the way, I wonder if Carmac has played Jake2 (a Java port of Quake2). There's some framerate info here: http://blog.andy-roberts.net/2005/11/28/jake2/


Of course, all of these things are IMPOSSIBLE in a scripting/markup language. You could probably even write an HDi emulator in Java. Java 6 already includes an API for scripting (including a Javascript interpreter).

'Nuff said.

This is what HDi's XML-style declarative structure addresses: cross platform capability without VM overhead.And on Blu-ray you've got HDMV for where declarative content is sufficient and you've got BD-J for where it isn't. Of course a VM is generally not going to outperform a native environment, but unless you've got an entirely homogeneous ecosystem with one processor and one OS, native isn't an option (and even then there are significant security risks with native code which a VM largely addresses). The fact that Java is the primary application environment on what is now 2 billion cellphones (nearly 90% of shipping phones worldwide) attests to the fact that a VM can work very, very well. Whatever negative experiences you've had with Java elsewhere has little bearing on the ability for Java to provide a compelling, productive user environment for Blu-ray Disc (and digital TV in general, as evidenced by its selection for MHP, OCAP, ACAP, and other global broadcast standards).

- Talk

Here's an interesting article to help combat the rampant FUD in this thread:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
[...]
Rampant FUD? Come on!

You've found a link to an interesting article. As always, one has to read such an article carefully, and think about it. In the "Conclusions"-chapter, the author complains about the following:

Two of the most interesting observations regarding this issue are that:
1. [snip]
2. that in web flame wars, people are happy to discuss their speed impressions for many pages without ever referring to actual data.Interestingly, the author does exactly what he's complaining about. He does not come up with information regarding environment, does not provide program code of the benchmarks he ran, does not give information which compiler version was used and with which invocation parameters the benchmarks were compiled exactly, and most importantly, he does not present the exact results. This is not a scientific approach, and makes it impossible to recreate the tests to verify the results.

Here is a different view on your article: http://www.freewebs.com/godaves/javabench_revisited/

However, I have my doubts that these articles are relevant for Java for your BD player, considering what was leaked about the functionality and the intended use-cases of BD-J.

I'll say this: I've never had anything in Java run what I would call fast. Except for when using MS's IE5 Java runtime that Sun sued to have killed (Because it had custom API extensions or w/e). *That* was a fast VM that worked for it's purpose. Sun Java has always been slow in my experience, even on fast systems.

On the other hand, C# and other managed .Net stuff may not be native code but I've never had any performance problems with them. And .Net is not tied to x86 either, .Net is available for other platforms, such as the 360 itself and some mobile/embededded type stuff. There's differences in those implementations but they're documented and you know what to expect there.

Obviously, Java COULD be fast, MS did it. Why can't anyone else? I don't see why we should need faster CPUs (native Java execution or not) to run it, I think its just really bad implementation of the JRE's that mainly causes problems.

I'll say this: I've never had anything in Java run what I would call fast. Except for when using MS's IE5 Java runtime that Sun sued to have killed (Because it had custom API extensions or w/e). *That* was a fast VM that worked for it's purpose. Sun Java has always been slow in my experience, even on fast systems.

On the other hand, C# and other managed .Net stuff may not be native code but I've never had any performance problems with them. And .Net is not tied to x86 either, .Net is available for other platforms, such as the 360 itself and some mobile/embededded type stuff. There's differences in those implementations but they're documented and you know what to expect there.

Obviously, Java COULD be fast, MS did it. Why can't anyone else? I don't see why we should need faster CPUs (native Java execution or not) to run it, I think its just really bad implementation of the JRE's that mainly causes problems.


I've had extensive experience with the Microsoft Java VM and it *WAS* the fastest VM - around the turn of the century. I've done a considerable amount of benchmarking for various projects and that old dog doesn't even come close to current Sun or IBM implementations.

Either people are living in the nineties or they're looking at poorly written applications. One or the other. Is Java for everything? No...I wouldn't write a MPEG4 encoder in it if I had a choice *BUT AT LEAST IT WOULD BE POSSIBLE*. Again, the same can't be said of scripting markup environments...like HDi.

Here's an interesting article to help combat the rampant FUD in this thread.Ok, I will admit Java has progressed, but don't think one article or benchmark is going to change the perception of Java. What I and others have been talking about is *our* personal experience with Java. Not a few numbers on some website that could be easily padded without knowing all the details. I have programmed in Java before, I have seen the Java applets on the web and used stand-alone programs on my pc and cell phone as well. Every single time it has been slow. Way slower than anything written in C++. If you are going to try to tell me that Java is faster than C++, I am not going to believe anything else you ever say. Its just not true.

'Nuff said.

BTW: I am not trying to say HDi is in any way better/faster than BD-J. Neither can hold a torch to native C++ code. Thats all I'm saying.

Ok, I will admit Java has progressed, but don't think one article or benchmark is going to change the perception of Java. What I and others have been talking about is *our* personal experience with Java. Not a few numbers on some website that could be easily padded without knowing all the details. I have programmed in Java before, I have seen the Java applets on the web and used stand-alone programs on my pc and cell phone as well. Every single time it has been slow. Way slower than anything written in C++. If you are going to try to tell me that Java is faster than C++, I am not going to believe anything else you ever say. Its just not true.

'Nuff said.

BTW: I am not trying to say HDi is in any way better/faster than BD-J. Neither can hold a torch to native C++ code. Thats all I'm saying.


That's not the only site to suggest Java is as fast or faster than C++ at certain benchmarks. There ARE advantages dynamic compilation.

But no, I don't think Java is faster than C++ in general. Just as I don't think C++ is faster than hand-tuned assembler. But you're not going to find C++ or assembler in devices without a unified architecture (at least not when quick development and security are requirements).

There are things Java is VERY good at. Companies like Google and E-Bay don't use Java because of contractual obligations. They use it because some very smart developers believe it's the best language to get the job done. It is the number one programming language on the planet.

BD-Java will be awesome. I have no doubts whatsoever.

Some good responses and interesting links.

Question for those in the know: do the VM implementations in current decks unclude a JIT compiler? Or any "native binding" interfaces to graphics acceleration hardware?

Some good responses and interesting links.

Question for those in the know: do the VM implementations in current decks unclude a JIT compiler? Or any "native binding" interfaces to graphics acceleration hardware?

Those are great questions. If I were to guess I'd say no on the JIT at this early stage (although software players and/or the PS3 may have a JIT implementation). Hopefully players that don't have a JIT can be upgraded via firmware. The performance differences can be night and day.

As far as native binding for graphics, the answer is always yes. However I suspect you're talking about 3D acceleration like OpenGL, etc. I doubt that's supported now but it could open up the door to some amazing effects on devices with graphics cards (like the PS3).

Good questions for an insider.

Question for those in the know: do the VM implementations in current decks unclude a JIT compiler?For the most part no. There is definitely room for improvement in existing models (should vendors choose to do so) and future models.

For the most part no. There is definitely room for improvement in existing models (should vendors choose to do so) and future models.

Any thoughts about the HW implications of including a JiT compiler? Required RAM, size of the VM + Compiler to be held in flash, etc...?

Are there many existing similar embedded devices (set top boxes, cell phones, etc...) that DO include a JIT that we can compare?

Java and Blu ray will become a real bugfest. No doubt about that.
Profiles mess, various player implementations, 'creative' programmers with studios each developing there own interactivity functionality.

Java in 'disposable' ce electronicst (cellphones, pda's, obselete blu ray players etc.) is used mainly for short lifetime products. Develop quick and never mind the bugs.

Java and Blu ray will become a real bugfest. No doubt about that.
Profiles mess, various player implementations, 'creative' programmers with studios each developing there own interactivity functionality.

Java in 'disposable' ce electronicst (cellphones, pda's, obselete blu ray players etc.) is used mainly for short lifetime products. Develop quick and never mind the bugs.


Amusing. I love the Internet.

Listen to what John Carmack has to say about Java (QuakeCon 07):
http://www.gametrailers.com/player/23293.html

He pretty much just confirms what I've been trying to say.

Amusing. I love the Internet.
So does everyone else. Given your handle which means it's certain you derive revenue from JAVA what else would we expect you to say? Kind of like asking Sony about BD.

We'll see. But given the varied CEs & hardware I'd say it will be a buggy nightmare.

Listen to what John Carmack has to say about Java (QuakeCon 07):
http://www.gametrailers.com/player/23293.html

He pretty much just confirms what I've been trying to say.
Hey now, don't listen to the likes of Carmac - listen to the authorities in this thread.

(did chuckle & the Jobs comments - the used car salesman of IT - no idea what he's talking about, but he can sell anything :D )

So does everyone else. Given your handle which means it's certain you derive revenue from JAVA what else would we expect you to say? Kind of like asking Sony about BD.

We'll see. But given the varied CEs & hardware I'd say it will be a buggynightmare.


Hey now, don't listen to the likes of Carmac - listen to the authorities in this thread.

(did chuckle & the Jobs comments - the used car salesman of IT - no idea what he's talking about, but he can sell anything :D )

How about asking Amir about HD-DVD? It sounds like you're offended I speak from an informed position. I can make money from a variety of programming disciplines. Right now I prefer Java for a whole host of reasons.

You don't have to be John Carmac or his ego to know you wouldn't write Doom 4 in Java. That said, MILLIONS of people play games written in Java. I was a big fan of the WWII flight sim IL-2 Sturmovik (it was recently on one of Gamespots obligatory "best of" lists). I was stunned to find out later it was powered by Java with native opengl bindings.

Anyway, equating high-performance gaming with interactivity on an optical disc is foolish regardless of credentials.

How about asking Amir about HD-DVD? It sounds like you're offended I speak from an informed position. I can make money from a variety of programming disciplines. Right now I prefer Java for a whole host of reasons.

You don't have to be John Carmac or his ego to know you wouldn't write Doom 4 in Java. That said, MILLIONS of people play games written in Java. I was a big fan of the WWII flight sim IL-2 Sturmovik (it was recently on one of Gamespots obligatory "best of" lists). I was stunned to find out later it was powered by Java with native opengl bindings.

Anyway, equating high-performance gaming with interactivity on an optical disc is foolish regardless of credentials.
If the world had listened to John Carmack, Direct3D would have been killed, and the gaming world would all run OpenGL. As a result, there would have been no DreamCast, no Xbox, and no xbox360 because without Direct3D there would be no gamingAPI for MSFT to extend the PC games over to XBOX.

Or Xbox could be running openGL.

Anyone who owns a recent cellphone or blackberry and have tried games on them know that in spite of inefficiencies, Java clients generally work for GUI stuff. There's about a billion of those things out there today, many of them do more than play ringtones.

How about asking Amir about HD-DVD? It sounds like you're offended I speak from an informed position. I can make money from a variety of programming disciplines. Right now I prefer Java for a whole host of reasons.
You say informed, I say biased - just an opinion. And I said nothing about background, simply revenue stream = bias (nor ability either). No negatives, just a "slant" comment.
If the world had listened to John Carmack, Direct3D would have been killed, and the gaming world would all run OpenGL. As a result, there would have been no DreamCast, no Xbox, and no xbox360 because without Direct3D there would be no gamingAPI for MSFT to extend the PC games over to XBOX.

Or Xbox could be running openGL.

Anyone who owns a recent cellphone or blackberry and have tried games on them know that in spite of inefficiencies, Java clients generally work for GUI stuff. There's about a billion of those things out there today, many of them do more than play ringtones.
The crucial point, w/o D3D the devices would exist they would simply use a different API.....OpenGL. At the time Carmac made those points OpenGL was more mature & had a better feature set. MS didn't want it because it wasn't theirs.

As the OP points out the blackberry has had issues. Cell phones is where I agree with Carmac - a good use for JAVA. Fixed platform & short life span = easy to make work. Long(er) life devices like BD players? Skeptical. The single biggest issue I (& quite a few others) have with JAVA is when you have varied platforms. The BD players aren't likely to be identical. How is one going to update them? Each CE is on their own? Doesn't bode well for compatibility w/ all features. Use the disc for updates? With differing hardware & likely varied states of software? Doesn't bode well.

As I've said many times "we'll see", but I'm a skeptic.

You say informed, I say biased - just an opinion. And I said nothing about background, simply revenue stream = bias (nor ability either). No negatives, just a "slant" comment.


My fortunes aren't even remotely tied to the success of BD-Java. It's true that I'm biased...and a quick perusal of your posting history reveals you are too. So we both have an opinion - that and a quarter will buy you a gumball at K-Mart.

When it comes to BD-Java, I prefer to be an optimist. Not just because I'm a fan of Java (and I am a fan) but because I think Blu-Ray is on it's way to winning this "war".

Any thoughts about the HW implications of including a JiT compiler? Required RAM, size of the VM + Compiler to be held in flash, etc...?A JIT implementation can be smaller than a non-JIT - it depends on lots of things The runtime RAM requirements can be tuned to the available footprint, so would be implementation and player-dependent.
Are there many existing similar embedded devices (set top boxes, cell phones, etc...) that DO include a JIT that we can compare?Can't really compare as it's apples-to-oranges. Many cellphones have JIT implementations, as do many of the OCAP set-top boxes now being shipped. In general a JIT implementation can increase performance 3X - 10X, though this can be very application dependent (i.e. an app where the bottleneck is I/O may not see much improvement).

- Talk

Java in 'disposable' ce electronicst (cellphones, pda's, obselete blu ray players etc.) is used mainly for short lifetime products. Develop quick and never mind the bugs.Then why has cable standardized on it via OCAP? Set-top boxes and TV's are far from "disposable".

- Talk

Ok, I'd just like to say that my mind may have been swayed a bit on this topic (specifically the merits of HDi versus BD-J). I had the pleasure of trying out the exclusive game included on the HD DVD version of 300. The game was very basic overhead 2D, like a board game, with HD clips of the film at key moments and decent production values, but it wasn't fun at all. I give them credit for bring out one of the first of its kind on the medium, but I hope thats not all HDi has to offer in terms of advanced interactivity.

The menus and options were pretty clunky (even compared to way the HD DVD menus usually work). Often it seemed like commands were ignored (I know the remote is responsive otherwise), and just slow in general. I died the first few times without even doing anything (until I did the tutorial). Then I played into it about 15-20 minutes and the battle was getting heavy, then the thing crashed on me. It just froze, I couldn't do a soft reset with the remote, I had to reboot the Xbox360. Not a very good first impression.

I just can't understand why the Xbox360 would be so slow on something like this. It has 3 processors, power couldn't have been the problem. Maybe it was just bad coding or a rushed job, but it was disappointing to say the least. What I have read about Dragon's Lair (on both formats) doesn't give me much hope either.

That being said, I am willing to give BD-J a shot. If it does indeed deliver what is promised, it is very possible it might surpass what is available on HDi. I think interactive features on HD/BD formats really have the potential to do so much more than just play movies. With a network connection, the possibilities are almost endless. I really hope that more compelling interactive content is forth-coming, and if it ends up being on BluRay, then I will definitely pick up a player. I still hold some hope that developers are just learning the ropes, I was particularly impressed with the features on FREEDOM 1, so I know HDi can do more. But I'm willing to give BD-J the benefit of the doubt for the time being.

Then why has cable standardized on it via OCAP? Set-top boxes and TV's are far from "disposable".

- Talk

These devices are all connected to a cable and software can be upgraded through the cable.

Many br player models do not have a network connector. Updating will be cumbersome.

Also the cable operators are smart enough to standarize. The basic functions are fairly simple and there is hardly content dependend interactivity going on.
I get the cable box from my cable service provider. It's a simple 1 to 1 relation.

With br interactivity things are not that straightforward and simple.
Many more players to the table tends to complicate the game.

I have no doubt great things can be accomplished with Java. But I fear programmers will lack the discipline and experience to keep it simple.

These devices are all connected to a cable and software can be upgraded through the cable.

Many br player models do not have a network connector. Updating will be cumbersome.Yet the fact is most of these devices will need updating. Even though all HD DVD players have network ports, I'm certain well under 50% of them are connected to a network, and probably a good percentage will never be connected to a network. In either case you have to make available the possibility of updating via memory card, CD, DVD, etc.
Also the cable operators are smart enough to standarize. The basic functions are fairly simple and there is hardly content dependend interactivity going on.There certainly will be. The cable operators intend to offer much of the interactivity you see on Blu-ray via Video on Demand, and network programming will be very interactive as the boxes are rolled out (i.e. vote for American Idol via your remote, follow the Olympic events you care about, etc.).
I get the cable box from my cable service provider. It's a simple 1 to 1 relation.Yes, but many/most TV's will ultimately be OCAP as well (Panasonic said most of their plasma line will be OCAP by 2009). Today you get your box from the cable company, but going forward that will be less necessary.
I have no doubt great things can be accomplished with Java. But I fear programmers will lack the discipline and experience to keep it simple.The discipline will come with experience. Don't forget, there's always a gatekeeper (i.e. the studio, the broadcast network, or the cable operator). Content which isn't up to snuff won't see widespread distribution.

- Talk

A JIT implementation can be smaller than a non-JIT - it depends on lots of things The runtime RAM requirements can be tuned to the available footprint, so would be implementation and player-dependent.
Can't really compare as it's apples-to-oranges. Many cellphones have JIT implementations, as do many of the OCAP set-top boxes now being shipped. In general a JIT implementation can increase performance 3X - 10X, though this can be very application dependent (i.e. an app where the bottleneck is I/O may not see much improvement).

- Talk

Thanks Talk.