Netflix Streaming Coming to PS3 Next Month

[obonicus]

It should be XML.

I'm not sure if you've followed industry trends, but the trend is moving away from using machine code to define interfaces into using standards like XML (or HTML/CSS ).

Dude, you're all over the place. One one hand you complain about performance of the JVM, but at the other you tout the advantages of browser-type tech.

DOM is not a light-weight representation. There's nothing 'light' about the way XML is used, for the most part.

It shouldn't have to be compiled to native code. You should be able to flip a layout value in a simple data file and that'll be the end of it. Any reasonably designed system would be like that.

Sure, I won't disagree, but this isn't the 'lightest' solution, it's the easiest one. Which might be just as important, you may not want to have to have Java programmers on hand for movie authoring. It just ain't light. Hardware acceleration solves the renderer problem (how widely available would it be, had HD-DVD won?), but the renderer's not the only issue here.

 

[Asher]

Seriously?

And it's not called Java, it's not claiming to be compatible with any other Java environment. You really shouldn't complain about RMS' fearmongering when you keep ignoring the actual details of the Microsoft/Java debacle and claiming that Sun will do something it only did once, under circumstances that are very different from anything you describe. What you're doing is FUD, plain and simple.

'Gosh, but they could cut us off!' Sure, if you have a history of breaking standards and not playing well with others.

Look, ALL I am saying is Java is NOT an open standard and you MUST license it from Sun and Sun CAN refuse to license it.

This isn't FUD, it's a simple fact. It is incorrect to say anyone can license Java and Sun will license it to them, because Sun can refuse to do so if they choose to.

 

[Asher]

Dude, you're all over the place. One one hand you complain about performance of the JVM, but at the other you tout the advantages of browser-type tech.

DOM is not a light-weight representation. There's nothing 'light' about the way XML is used, for the most part.

I honestly have no clue what you're talking about. Compare the complexity of DOM/JS to that of a JRE and it's light. Very light.

Sure, I won't disagree, but this isn't the 'lightest' solution, it's the easiest one. Which might be just as important, you may not want to have to have Java programmers on hand for movie authoring. It just ain't light. Hardware acceleration solves the renderer problem (how widely available would it be, had HD-DVD won?), but the renderer's not the only issue here.

It is light. I do not understand why you think DOM/JS is anywhere near as heavy and complex as a JRE is. It's simply an incomprehensible statement.

DOM/JS is a lightweight solution that also happens to be easier compared to a full-out JRE. Its scope is more narrow and its use more specialized.

 

[patsu]

MS didn't submit it presumably because it'd be overkill. They were fully behind HDI.


And gmail is famous for doing as much as it can client-side..using Javascript and the DOM. This is perhaps the worst example you could've possibly given as it's a tremendous example of the power of JS/DOM/etc.

As a bonus, it doesn't at all use Java in any way.

Not exactly, Java is there to manage the sessions for millions of users. I think it's a great counter-example for people who claim that Java is slow. They would have used C or other native languages to handle the backend. As for JavaScript handling the frontend, it's because they want it to behave as much as possible like a regular native UI app. JavaScript is the de facto choice here since it's included in every browser.

YES. That is the point. .NET would be overkill for this as well! And yes, it is overkill to have to write Java code to change the color of a video scrubber.

It should be XML.

At UI development level, it should be a field change or a color picker. XML, Java or .NET is irrelevant here.

I'm not sure if you've followed industry trends, but the trend is moving away from using machine code to define interfaces into using standards like XML (or HTML/CSS ).

Sure, but this is implementation details. Afterall Java uses XML too. The authoring tool provider would write the config into an XML file for the run-time to read. Again, this doesn't say anything about Java being an overkill.

It shouldn't have to be compiled to native code. You should be able to flip a layout value in a simple data file and that'll be the end of it. Any reasonably designed system would be like that.

It is native code during run-time. Again, none of the above precludes Java. It's a development tool problem.

This is how it works in iTunes Extras, Sony PSP movies, HDi, Silverlight video players, HTML5 video, etc. BD-J on Bluray is the odd man out here, and it's a very silly design that is overkill.

Huh ? We were talking about run-time. If you want to talk about development time, then yes, Blu-ray authoring can be done in XML if you want too, like this one ?
http://www.sonycreativesoftware.com/products/bluprint.asp?page=whatsnew

Again, none of this means that Java is slow, or overkill. It only speak of your personal preferences and desire for a simpler development tool, which is being addressed today.

You are completely missing the point. It's not JUST about development convenience, it's about the complexity of the tool from end to end. Yes, Visual Studio has an interface builder but that is not the point at all. First of all, .NET on Bluray/HD DVD would be as every bit as stupid as Java would be. Second of all, this is a terrible example on your part again. The new Visual Studio apps, even when using this interface builder, write interface designs to XML and NOT to machine code or code of any kind. The layout and the back-end code are separate, as they should be.

That's because we were talking about run-time and now you want to switch to development tool. At run-time, naturally, everything goes to machine code. At development time, it depends on what tool you use, it could be XML should you desire.

As for whether it's stupid to have .NET on Blu-ray player, I'd say Java is a better choice since it is proven in small devices long ago, and there are many implementations and experiences that BDA could rely on.

But, again, this isn't the point. BD-J is heavy from start to finish. It doesn't matter if there's an interface builder for it if you need to create custom classes just to implement an ever-so-slightly customised video scrubber. That's <em>overkill</em>. It increases loading time for users, it increases development efforts and complexity for developers. It's just overkill.

As far as I know, Java has been running on small devices to heavy weight Internet app efficiently. There are lousy implementations, but it doesn't mean the language has to be slow. Load time increases could be due to system issues as well as the VM loading, but beyond that, it can be fast.

Then this is a terrific example of why BD-J was a bad idea. The code isn't even portable, apparently. You have repeatedly used Netflix as an example of the triumph of BD-J, when it could just as easily have been implemented in HDi and work on every HD DVD player ever made, from the start.

Why is it a bad idea when NetFlix could put a solution together quickly ? HDi may work but again, only on one vendor solution.

While the disc may not work on another Blu-ray player, I did not say the code is not portable. They are different things, you are too quick to leap to conclusion, and I don't know the answer. ^_^

I am utterly gobsmacked right now.

Yes, HDi requires DOM and JScript runtimes. Which are smaller and less complex by orders of magnitude compared to the JRE.

Please provide a number.

And how have I simplified Java run-time issues? They're all there. You can either use JIT which results in painfully long loading times for what should be simple tasks like playing a video, or you can use simple bytecode interpretation which is slow all the time. In any case, Bluray interfaces are not as responsive as they should be.

You claimed that Java is slow and overkill without considering the application and techniques.

To be perfectly honest, products like this are a reason why BD-J was overkill and a bad idea. Studios are going to make content only accessible to people with iPhones/iPod touches or "other wifi devices"? If I'm watching a Bluray on a 42" LCD, why would I want to use a 3.5" display on my iPod or iPhone? If I'm looking at the iPod or iPhone I'm not looking at the TV.

This is another terrific example of the overkill of BD-J resulting in solutions looking for problems.

Blu-ray is a media platform. Having a programmatic way to manage content and exchange with multiple devices is a natural next step.

e.g., I don't think it's a bad idea to allow me to send a digital coupon directly from my iPhone (or other WiFi devices) to my Blu-ray player to stream and view a new movie.

... or to allow me to continue viewing from time T after I copied an in-progress movie from my Blu-ray player to my iPhone.

Over here, I think you'll have to use your imagination more. The studios will eventually figure out a winning formula.

 

[obonicus]

I honestly have no clue what you're talking about. Compare the complexity of DOM/JS to that of a JRE and it's light. Very light.

We're not talking about complexity. I'm talking about speed and memory usage. DOM could be worse (it's not SAX) and it does get a speedup in exchange for memory usage, but it's still a mess. When you suddenly expose the document tree via a Javascript representation, it just gets worse.

It is light. I do not understand why you think DOM/JS is anywhere near as heavy and complex as a JRE is. It's simply an incomprehensible statement.

On embedded JREs? I do think so. DOM has compromise written all over it, like most XML tech. Are you really going to say that, given hardware-accelerated graphics primitives for both parties you can run fully-dynamic xml+JS faster than bytecode? At this point I think we need benchmarks, and I don't think we're even going to agree on them when they do show up.

DOM/JS is a lightweight solution that also happens to be easier compared to a full-out JRE. Its scope is more narrow and its use more specialized.

Sure, its scope is more narrow, but it was never designed to be speedy.

 

[obonicus]

Look, ALL I am saying is Java is NOT an open standard and you MUST license it from Sun and Sun CAN refuse to license it.

This isn't FUD, it's a simple fact. It is incorrect to say anyone can license Java and Sun will license it to them, because Sun can refuse to do so if they choose to.

This is FUD. No, it's not open. Yes, Sun can ostensibly refuse you. But until you can come up with an example that isn't Microsoft, bringing up the possibility of something that hasn't happened is exactly what you were accusing RMS of doing, fearmongering.

 

[makattack]

Dude, you're all over the place. One one hand you complain about performance of the JVM, but at the other you tout the advantages of browser-type tech.

DOM is not a light-weight representation. There's nothing 'light' about the way XML is used, for the most part.

Uhm, in my experience XML was initially used for backend interoperability... not for client side processing so much. In fact, XML was sort of like HTML, but for server side data definition and transactions.

Anyway, you do realize you can stream process XML and not process XML as a document object model as well?

I think this discussion is getting people confused about a development language/virtual machine implementation model being used by BDJ vs. HDi (which I acknowledge to knowing nothing about until this thread) which sounds a bit more like a specification for interoperability using XML document specs and Javascript libraries that implement an interface.

Clearly, if that's the case... one is a much "lighter" implementation, but may not be as flexible.

 

[obonicus]

Uhm, in my experience XML was initially used for backend interoperability... not for client side processing so much. In fact, XML was sort of like HTML, but for server side data definition and transactions.

Right, but for backend interoperability being 'light' wasn't really a main concern. Maybe I'm being too negative on XML in general, my main beef right right now is with DOM/JS (I don't like DOM to begin with).

Anyway, you do realize you can stream process XML and not process XML as a document object model as well?

Yep, but we are talking about DOM/JS.

 

[Asher]

Not exactly, Java is there to manage the sessions for millions of users. I think it's a great counter-example for people who claim that Java is slow. They would have used C or other native languages to handle the backend. As for JavaScript handling the frontend, it's because they want it to behave as much as possible like a regular native UI app. JavaScript is the de facto choice here since it's included in every browser.

First of all, I've already said the app server market is a different beast altogether.
Second of all, I've not found a single ounce of evidence that Google uses Java for the gmail session management. Where did you hear that?

At UI development level, it should be a field change or a color picker. XML, Java or .NET is irrelevant here.

Again, I couldn't care less about what tool the guys use to do this. I don't care if it abstracts it away from the designer that they need to deploy custom classes just to change the color of something. It's a poor design for the system as a whole. Custom classes have ramifications in that this is code bloat, it's more that needs to be compiled, and it'll ultimately impact the user's experience.

Sure, but this is implementation details. Afterall Java uses XML too. The authoring tool provider would write the config into an XML file for the run-time to read. Again, this doesn't say anything about Java being an overkill.

This is not how BD-J is designed.

It is native code during run-time.

No, not fully. Do you think JIT code never needs to deal with memory management or garbage collectors? That it doesn't touch the JRE stack?

Again, none of this means that Java is slow, or overkill. It only speak of your personal preferences and desire for a simpler development tool, which is being addressed today.

You keep repeating it but that doesn't make it true. Any time code needs to be created to do trivial layout changes, it's a sign you didn't design your architecture properly. It's overkill.

The vast majority of BD-J use is for trivial changes to the menu scrubber. If you're not doing any advanced programming (games, etc) there's no reason whatsoever for you to actually have to have new CODE being generated.

As for whether it's stupid to have .NET on Blu-ray player, I'd say Java is a better choice since it is proven in small devices long ago, and there are many implementations and experiences that BDA could rely on.

Apparently you've not heard of the .NET Compact Framework. What do you think Ford Sync is written in? I've written .NET CE apps for Windows Mobile for quite some time as well. This is not a competitive advantage of Java.

As far as I know, Java has been running on small devices to heavy weight Internet app efficiently.

I'm not sure how aware you are about the massive differences between Java app servers, Java desktop apps, and embedded Java apps. They all share the Java language, but there are tremendous differences aside from that. They're not to be confused.

Why is it a bad idea when NetFlix could put a solution together quickly ? HDi may work but again, only on one vendor solution.

I'm perplexed why you keep coming back to this "only on one vendor solution". The Netflix Bluray disc only works on PS3s, an HDi implementation would work on every HD DVD player ever made. To the end user, what's the difference here?

Please provide a number.

I'm not going to spend my sunday googling memory usage of various JRE and JS/DOM configurations. Again, I've been in the mobile space for a few years and I've seen this extensively on Android and Blackberry phones (Java), Windows Mobile phones (.NET CE), and now WebOS phones (DOM/JS). DOM/JS is less flexible and more simple, JREs are complex beasts. That is reflected in both the computational power required, as well as memory usage.

You claimed that Java is slow and overkill without considering the application and techniques.

I've done so. No matter what you do with Java, you've got performance considerations. Initial loading time or run-time, choose your poison. You can't wave your hands and pretend Java will always run as fast as native code in all situations, which is effectively the vibe I'm getting from you.

Over here, I think you'll have to use your imagination more. The studios will eventually figure out a winning formula.

My imagination is just fine. The problem with some people is an overactive imagination. I've seen it time and time again in my career with people with overactive imaginations overengineer what should be simple solutions, and in the end people end up paying for it. Whether it's with buggy software, long development times, or impact to the user experience...nothing is free where complexity is concerned.

You need to keep in mind that the VAST majority of people who watch movies do NOT care for all of this nonsense that you keep extolling about BD-J capabilities. To talk to iPhones wirelessly, to play mind-numbingly simple BD-J games, to create their own Fast and the Furious car, etc. They like to watch movies, and they like to do so simply and easily and with consistency.

I'm a very firm believer of KISS and consistency. As I've said before, studios are looking to start abusing BD-J like many marketers are abusing Flash in the desktop space. Just because you can, doesn't mean you should.

Anyway, as fun as this discussion has been I can tell we're starting to enter a loop here, so I'll retire. Ultimately HDi is dead and we're all stuck with BD-J and its associated real-world performance quirks that some people choose to believe don't exist, so there's little point arguing about it now.

 

[Asher]

I couldn't resist...

We're not talking about complexity. I'm talking about speed and memory usage.

Are you telling me you don't believe there's a correlation between complexity and speed and memory usage?

Are you really going to say that, given hardware-accelerated graphics primitives for both parties you can run fully-dynamic xml+JS faster than bytecode?

I can do you one better -- I can promise you that. I've ported an app written in Java on an ARM chip to one written in JS/CSS/DOM on a very similar ARM chip and the JS/CSS/DOM one was faster in every user-perceivable way: loading time, UI responsiveness, and overall program flow (eg, clicking the "Search" button in our app populating the results list quickly and letting the user action the items faster). And the phone with the Java RE was a far more mature implementation. In fact the SDK for the JS/CSS/DOM phone won't even be officially public til the end of the month. And the JS-powered phone does use Google's V-8 JS engine, FWIW. It's even doing some fairly heavy math (geometry calculations relating to polygons, circles, and geocoded data).

 

[obonicus]

Are you telling me you don't believe there's a correlation between complexity and speed and memory usage?

Depends by what you mean by complexity. In the computer theoretic sense there isn't just a correlation, but we're not talking about that. In terms of technology in general? Not necessarily. C++ is an insanely complex language, it's still faster and more memory-friendly than most of what we're talking about (and C is far less complex and has a heads-up on it). Complexity in the sense we're talking about is heavily tied into implementation; a few years ago I remember benchmarks that had a garbage-collected language like OCaML running on par with C++ just because it had a really amazing compiler.

I can do you one better -- I can promise you that. I've ported an app written in Java on an ARM chip to one written in JS/CSS/DOM on a very similar ARM chip and the JS/CSS/DOM one was faster in every user-perceivable way: loading time, UI responsiveness, and overall program flow (eg, clicking the "Search" button in our app populating the results list quickly and letting the user action the items faster). And the phone with the Java RE was a far more mature implementation. In fact the SDK for the JS/CSS/DOM phone won't even be officially public til the end of the month. And the JS-powered phone does use Google's V-8 JS engine, FWIW. It's even doing some fairly heavy math (geometry calculations relating to polygons, circles, and geocoded data).

I'll defer to you on that. It'd still be nice to see more controlled benchmarks, to see that the comparison was fair to begin with, but I won't doubt you.

 

[patsu]

First of all, I've already said the app server market is a different beast altogether.
Second of all, I've not found a single ounce of evidence that Google uses Java for the gmail session management. Where did you hear that

Changing story again ? One of the Gmail founding members is a personal friend. I was surprised he/they picked Java too.

Again, I couldn't care less about what tool the guys use to do this. I don't care if it abstracts it away from the designer that they need to deploy custom classes just to change the color of something. It's a poor design for the system as a whole. Custom classes have ramifications in that this is code bloat, it's more that needs to be compiled, and it'll ultimately impact the user's experience.

Hm ? The only difference is Java exposes the UI class libraries while on JavaScript you rely on built-in ones. They both require someone to implement them. As long as the Java VM compiles the UI classes into native code, there is very little difference to an outsider.

This is not how BD-J is designed.

Doesn't matter, the authoring tool can still allow you to use XML to config your UI should you desired. During run-time, it will be executed as efficiently as the VM allows.

No, not fully. Do you think JIT code never needs to deal with memory management or garbage collectors? That it doesn't touch the JRE stack?

JScript has GC too. I don't see how it's majorly different from Java.

You keep repeating it but that doesn't make it true. Any time code needs to be created to do trivial layout changes, it's a sign you didn't design your architecture properly. It's overkill.

Ha ha, it only means that the developer can reuse the class to create something else. He can also choose not to customize the class and just set the attribtues like any CSS-styled elements. Doesn't mean it's overkill.

The vast majority of BD-J use is for trivial changes to the menu scrubber. If you're not doing any advanced programming (games, etc) there's no reason whatsoever for you to actually have to have new CODE being generated.

There are BD-Live games, chat systems, live streaming, WiFi devices syncing and more.

Apparently you've not heard of the .NET Compact Framework. What do you think Ford Sync is written in? I've written .NET CE apps for Windows Mobile for quite some time as well. This is not a competitive advantage of Java.

True enough ! Then it may be a blunder on MS's part not to submit CLR stuff to BDA. All the media/information devices, from the battery-limited cellphones, cable settop boxes (tru2way), game consoles, and PCs have a "complete" 3rd party developer run-time (Java VM and/or CLR run-time). They should have guessed that the studios have the ambition to bring a fully programmable environment to their next gen movie player platform too.

A one-off HDi platform would not compare favorably to something like Java or CLR.

I don't know whether it's coincidence or planned, the tru2way cable settop boxes also use Java. The studios may be able to repurpose their programs easier with BD-J.

I'm not sure how aware you are about the massive differences between Java app servers, Java desktop apps, and embedded Java apps. They all share the Java language, but there are tremendous differences aside from that. They're not to be confused.

Sure, each segment of devices have a tailored library and run-time. Just like you'd need to tailor CLR for different devices too.

I'm perplexed why you keep coming back to this "only on one vendor solution". The Netflix Bluray disc only works on PS3s, an HDi implementation would work on every HD DVD player ever made. To the end user, what's the difference here?

From the industry perspective ? It's just how best practices standards work... like IETF requiring 2 or more implementations to exist and interoperate before standardizing on a draft.

And yes, the consumer doesn't care whether the PS3 disc works with the Samsung disc. But they care that the same Blu-ray movie works on all Blu-ray players. Took a while, but the situation has improved.

As bkilian mentioned, the studios have come a long way. It is not easy to create a hardware-neutral platform, it took Microsoft multiple interations to improve Windows too.

I've done so. No matter what you do with Java, you've got performance considerations. Initial loading time or run-time, choose your poison. You can't wave your hands and pretend Java will always run as fast as native code in all situations, which is effectively the vibe I'm getting from you.

Even for a simple "Hello world" program ?
There are very limited resources on Blu-ray players, so that statement applies to HDi too. And it depends on what (complex enough) problem you're trying to solve. 3D gaming is doable on Blu-ray players. The studios will experiment with more.

As for running Java at native speed, the chipset providers have been working on it for 2-3 generations now. They will get better at it.

My imagination is just fine.

blah...

I am a firm believe of KISS too. But it does not mean Java is overkill or slow. It depends on what the final goal is.

 

[Asher]

I'm not going to get into the rest (frankly because it's ridiculously silly and we've already been over most of it, and I lack your stamina for rehashing), but I'm going to ask yet again if you can cite something which claims Google uses Java in any way for gmail.

I've a couple friends at Google (none of which work on gmail), but from my understanding that would be tremendously out of character given how obsessive Google is over control over their own technology. There's not a single piece of off-the-shelf technology they use that they don't modify the hell out of, including stuff like MySQL. I simply cannot and will not believe they use Java in gmail unless there's a reliable citation.

Edit: Your friend may be referring to Closure Templates? They're used minimally in gmail for page templating, with the heavy lifting done with its client-side Javascript counterpart and apparently it's written in Java on the serverside. That's far from gmail being powered by Java, though.

 

[obonicus]

Google has a ton of NIH but they certainly use Java (you can find quotes here and there). It's not like patsu's saying that they're running apache tomcat. I know that they only switched off .NET for orkut when it couldn't handle their workload, but I can't remember what they moved to.

Not saying gmail uses Java, rather objecting to the 'obsessive about controlling tech' notion preventing them from using it.

 

[makattack]

Even for a simple "Hello world" program ?
There are very limited resources on Blu-ray players, so that statement applies to HDi too. And it depends on what (complex enough) problem you're trying to solve. 3D gaming is doable on Blu-ray players. The studios will experiment with more.

As for running Java at native speed, the chipset providers have been working on it for 2-3 generations now. They will get better at it.

I am a firm believe of KISS too. But it does not mean Java is overkill or slow. It depends on what the final goal is.

Funny you say this, but yes... here's an example (albeit overly simple and in my opinion doesn't say much other than the overhead of starting a JVM is significant):

makd@breakaway ~ $ cat HelloWorld.java hw.cpp
class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}

#include <iostream>
using namespace std;
main()
{
cout << "Hello World!" << endl;
return 0;
}
makd@breakaway ~ $ time javac HelloWorld.java ; time g++ -o hw hw.cpp

real 0m0.677s
user 0m0.520s
sys 0m0.040s

real 0m0.352s
user 0m0.280s
sys 0m0.020s

makd@breakaway ~ $ time java HelloWorld ; time ./hw
Hello World!

real 0m0.094s
user 0m0.010s
sys 0m0.020s
Hello World!

real 0m0.002s
user 0m0.000s
sys 0m0.000s

And my home PC specs:
makd@breakaway ~ $ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.2/work/gcc-4.4.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.4.2/python --disable-libgcj --with-arch=i686 --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.2 p1.0'
Thread model: posix
gcc version 4.4.2 (Gentoo 4.4.2 p1.0)
makd@breakaway ~ $ java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)
makd@breakaway ~ $ uname -a
Linux breakaway 2.6.31-gentoo-r6 #1 Fri Nov 13 20:18:57 EST 2009 i686 Intel(R) Pentium(R) M processor 1.86GHz GenuineIntel GNU/Linux

 

[patsu]

If your needs are that simple, then your overhead will be higher when loading the VM.

Then again, if you're that concerned with performance, get the VM to install your simple program to native code directly. The jbed embedded VM for example allows you to do that.

You can stop where you're and think that this is all Java's fault. Or you can use the right Java tool for the job. The choice is really up to you.

EDIT: OTOH, if you need a sand box and bytecode interpreter environment (for security reasons), then the VM may be helpful despite the longer load time.

 

[Asher]

patsu, the point is the needs ARE that simple a huge amount of the time in the BD-J space. You want subtle tweaks, simple menu systems, etc. If you need to load the JRE and then you also need to "install" the code to transform it to native code first, that's considered overhead. It's also considered by some to be overkill.

You simply cannot ignore the overhead Java introduces in various ways: JRE start-up time, JIT compile time, Java stack performance issues, whatever you have. They're going to be there by virtue of running Java, and if you're using Java you need to look at that whole picture and not just the resulting JITed code.

What do you think your player is doing during the 30s you see the "Loading" screen on Bluray discs? That kind of stuff should be unacceptable for a simple movie disc.

 

[Arwin]

It must have been a tough decision - it was the 'safest' bet back then in terms of choosing a future proof system, I think, and I still think it's probably the best solution overall. The startup times haven't bothered me so far either, they don't feel that different from DVD on the PS3 at least, though maybe I should test the actual difference sometime.

 

[tuna]

Look, ALL I am saying is Java is NOT an open standard and you MUST license it from Sun and Sun CAN refuse to license it.

This isn't FUD, it's a simple fact. It is incorrect to say anyone can license Java and Sun will license it to them, because Sun can refuse to do so if they choose to.

If Java is open enough to be included in every GNU/Linux distro under the sun it is open.

What you can't do is call something "Java" without paying money to Sun (and passing their compability tests). This is similar to how RHEL is free software and CentOS exist (but can not mention Redhat anywhere). You can take the most used Java implementation and port it to anything you want as long as you follow the GNU GPLv2 license.

 

[makattack]

If Java is open enough to be included in every GNU/Linux distro under the sun it is open.

What you can't do is call something "Java" without paying money to Sun (and passing their compability tests). This is similar to how RHEL is free software and CentOS exist (but can not mention Redhat anywhere). You can take the most used Java implementation and port it to anything you want as long as you follow the GNU GPLv2 license.

Actually, Java, from Sun, is not open enough to be included in every GNU/Linux distribution.

I use gentoo, and I have to do the following to install java sdk/jre from Sun:

http://www.gentoo.org/doc/en/java.xml

The default jre that would be installed is icedtea (http://icedtea.classpath.org/wiki/Main_Page) if you don't specifically configure your system for the Sun JDK.

You also have to edit your /etc/make.conf file to accept a Sun license. If you also install an older JDK from the 1.4 version, you'll need to download the install file from Sun before you can emerge it.