I bet NAMCO would have loved to sue them. With Google's big fat wallets they're a mouthwatering target for lawyers. They'd probably win too. Imagine the settlement theyd get for all the millions and millions of people that played it.
But no, There's no way Google would have made that without permission. They're not stupid. I expect they paid NAMCO a hefty sum for the right to make that. It shows how Google is willing to spend serious cash purely to show off how awesome they are. For all the great publicity it got them, I'd say it was well worth the investment.
One reason... security. Prevents a unstable application from growing out of control, causing the whole system to start paging which with a GC becomes a diaster, dragging the whole system to a hault makign it unresponsive. So you set a heap size to "more than you'll ever need" so that it aborts if something goes wrong. There are technical advantages too. But still... I agree. The fixed heap limits are more of a pain than a benifit, especially when the default setting for the client JVM was 64MB until recently because it handnt been changed since around 1997.
To Oracle's credit, when Eclipse dev's reported the issue (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969236) Oracle immediately reverted the change within 2 days (http://hg.openjdk.java.net/hsx/hsx17/baseline/annotate/1771222afd14/make/hotspot_distro). They could have argued that it was Eclipse's fault for depending on the value in the first place and that rebranding their VM is something they should be allowed to do. But they put the best interest of other applications first.
Still, it raises an issue that no one has really bothered with before. There are many Hostpot "vendor specific" options that are very commonly used. Almost every large application would configure heap sizes. There should be a standardized mechanism to define these options and thus avoid these very problems.
Im skeptical about the future of SIMD and even instruction level parallelism in general for massively parallel processors.
The problem with this is that in order to get maximum utiliasation of all of the ALUs in the processor, you have to fill the entire vector with data that you can perform the SAME operation on. This means its up to the programmer or compiler to write highly vectorizable code. If you cant fill these huge 512-bit vectors, arithmetic units are going to be idle.
nvidia realised this years ago, and so since the G80 their architectures have been scalar. Without vectors you can run alot more scalar threads while keeping ALL the units busy all the time. Win Win.
I'll need some serious convincing if I'm to believe Intel is a real threat to nvidia in this space, especially for GPGPU.
Because as the article says, Java has a well defined and correctly implemented memory model that provides certain essential guarentees about ordering and memory consistency when dealing with high levels of concurrency. C++ does not (in its current form) have any well specified memory model, making his techniques impractical, if not impossible, since the behaviour is unpredictable. To acheive concurrent data structures in C++, the only way to do it safely, correctly and in a portable way, is to use locks. For this reason, you can expect to get much better performance in highly concurrent environments with Java with than you would get with C++.
The next version of C++ in development, is trying to provide such a memory model, based on Javas.
Schwartz is sencerely all for oepn source, and he insists he's not interested in sueing anyone over patents. They might sue over license infringement of course, but in this case there is none. It's all Apache code. The only sore point is that Android doesnt include a complete and compliant Java stack (neither JME or JSE), only a subset, so they wont be able to certify it as a compliant implementation, and therefore it's technically not 'the Java platform', it just looks alot like it. Google knows this, so they've been careful in their videos to only say 'written in the Java programming language'. Google and Sun are friends. This will be good for Java. Sun will no doubt provide some tooling support in NetBeans. I see no chance of any 'showdown' here.
I think thats a bit harsh. He didnt even use the term 'open source', he just said 'open' and clarified what he meant by it, which is that anyone can write software for it, which is true (contrast that to the pre-SDK iPhone). I think his concern is a valid one. You could imagine a malicious application on the phone that uses Bluetooth to detect other phones nearby and spam them with SMS messages or something. But I'm sure google's thought of this and there will be security mechanisms, permissions, signed applications with digital certificates etc. etc.
I'll confess I hadnt read the complete article at the time (hey its long! blame the rush to comment early) but I have since. The summary doesnt say that it wasnt a complete phone (a phone can also be a platform, which the iPhone + SDK will be, and the SavaJe built on the JavaFX platform). but I read the article and it turns out its not that. My comment was more of a reaction of suprise since I was expecting something iPhone like. There are already several platforms around. iPhone, Java ME (though its technology is now outgrowing it), OpenMoko, JavaFX,.NET Compact Framework. I wanted to see a device that was going to make me go 'wow'. But we'll have to wait and see what google's partners come up with.
So it's just a platform. I'm a little dissapointed. I think alot of us were waiting for a iPhone competitor. But so far it's just another linux and Java based software stack. What sets this platform apart form the rest?
The default "cross platform" look and feel is indeed hideous, which is why most people would enable the native platform look and feel. The native platform look and feels were pretty bad in the past, but in Java 6 they're close to perfect, both on Windows and GTK. As for the cross platform look and feel, the Swing team have been working furiously to produce a modern replacement that will be available in a Java 6 update release early next year. It's called the Nimbus look and feel. Early screenshots available at http://www.galbraiths.org/blog/category/nimbus/ and http://www.jasperpotts.com/blog/category/nimbus/
Glassfish, Tomcat and Resin are all indepedant 100% pure Java webservers, all massively scalable and capable of processing 1000's of concurrent connections with performance comparable to Apache.
Yeah, I had a problem with that too. Because they added proprietary extensions that breached the specification (including Windows specific features), as well as omitting required features. Code written for the Microsoft VM wouldnt run on anyone elses. An implementation must be certified as compliant in order to use the Java brand. Microsoft's wasnt, so Sun sued. They won, and rightfully so.
But I'm glad this happened. It caused Microsoft to go off and create rival platform (.NET) and a rival language (C#). Maybe not so great for Sun, but great for the developer community, because it created good solid competition and both platforms are advancing at a rapid pace because of this.
For client Java developers like myself, the availability of the runtime is definitely the biggest challenges we face. Most computers do have a Java runtime installed, but few have the very latest, which is a shame because the last couple of releases have been MAJOR advances over 1.4 and earlier, which were admittedly pretty crappy for the client side. But Java 6 is excellent, but since it was only released in December, most people dont have it, and dont want to download even 7MB for it, and Java 7 is shaping up to be even more significant than Java 6.
But I'm afraid, a native compiler wont solve the problem. You'd still need the libraries somewhere. So they'd still have to be installed previously, or include them with the application. Either way, there's downloading to be done. (though one of Java's major advantages is that once the platform IS installed, the actual applications tend to be remarkably small, because so much functionality is in the platform, and because of the amazing pack200 classfile compression).
Plus, believe it or not, contrary to popular belief, an ahead-of-time native compiler would actually perform very poorly. The nature of the Java language depends on the runtime optimizations in order to achieve high performance. But that ends up being a good thing, because runtime optimzations allow it to optimize everything a C++ compiler can, and so much more.
Still, Sun is well aware of the deployment problem. They have an entire team working to solve it in a future release targeted for early next year. Basically the initial download will be tiny (just a couple of MB) which contain the most common libraries, and the rest will be streamed in the background while the app is already running. Hopefully this will work out well. Early reports are promising. Deployment is a hard problem when your technology isnt bundled with the OS, but it is being worked on!
Fortunately the GNU Classpath guys are right on board with OpenJDK. One of their most prominent members Dalibor Topic (who's the lead on the Kaffe VM) is on the OpenJDK governence board and works with Sun and other representivies on managing the project. Other promiment members like Roman Kennke, David Gilbert, Mario Torre and others. are active on the OpenJDK mailing lists and submitting patches. They are all interested in becoming regular contributors to the project.
Other GNU Classpath developers working for Red Hat were very quick to produce a version of OpenJDK using pieces of Classpath to fill the wholes of "encumbered" components that havent been open sourced (like the font, graphics and sound engines that were licensed by Sun by 3rd parties). This is called IceTea. Though its more of a quick 'n dirty temporary project to have a completely GPL JDK right now until the holes can be plugged properly. For example, Sun released a more sophistated FreeType based font engine this week, and the rest of the holes will eventually be filled. But for now, IceTea is a great playground for experimentation. And as far as I can tell, Red Hat wants to contribute anything useful back in OpenJDK.
You might that the GNU Classpath guys would be dissapointed, feeling that their hard work is obsolete, but no, they're happy because they know they were a big part of the reason why OpenJDK exists, and they're looking forward to contributing.
Slashdot Mirror
I bet NAMCO would have loved to sue them. With Google's big fat wallets they're a mouthwatering target for lawyers. They'd probably win too. Imagine the settlement theyd get for all the millions and millions of people that played it. But no, There's no way Google would have made that without permission. They're not stupid. I expect they paid NAMCO a hefty sum for the right to make that. It shows how Google is willing to spend serious cash purely to show off how awesome they are. For all the great publicity it got them, I'd say it was well worth the investment.
One reason... security. Prevents a unstable application from growing out of control, causing the whole system to start paging which with a GC becomes a diaster, dragging the whole system to a hault makign it unresponsive. So you set a heap size to "more than you'll ever need" so that it aborts if something goes wrong. There are technical advantages too. But still... I agree. The fixed heap limits are more of a pain than a benifit, especially when the default setting for the client JVM was 64MB until recently because it handnt been changed since around 1997.
To Oracle's credit, when Eclipse dev's reported the issue (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969236) Oracle immediately reverted the change within 2 days (http://hg.openjdk.java.net/hsx/hsx17/baseline/annotate/1771222afd14/make/hotspot_distro). They could have argued that it was Eclipse's fault for depending on the value in the first place and that rebranding their VM is something they should be allowed to do. But they put the best interest of other applications first. Still, it raises an issue that no one has really bothered with before. There are many Hostpot "vendor specific" options that are very commonly used. Almost every large application would configure heap sizes. There should be a standardized mechanism to define these options and thus avoid these very problems.
Im skeptical about the future of SIMD and even instruction level parallelism in general for massively parallel processors. The problem with this is that in order to get maximum utiliasation of all of the ALUs in the processor, you have to fill the entire vector with data that you can perform the SAME operation on. This means its up to the programmer or compiler to write highly vectorizable code. If you cant fill these huge 512-bit vectors, arithmetic units are going to be idle. nvidia realised this years ago, and so since the G80 their architectures have been scalar. Without vectors you can run alot more scalar threads while keeping ALL the units busy all the time. Win Win. I'll need some serious convincing if I'm to believe Intel is a real threat to nvidia in this space, especially for GPGPU.
Because as the article says, Java has a well defined and correctly implemented memory model that provides certain essential guarentees about ordering and memory consistency when dealing with high levels of concurrency. C++ does not (in its current form) have any well specified memory model, making his techniques impractical, if not impossible, since the behaviour is unpredictable. To acheive concurrent data structures in C++, the only way to do it safely, correctly and in a portable way, is to use locks. For this reason, you can expect to get much better performance in highly concurrent environments with Java with than you would get with C++.
The next version of C++ in development, is trying to provide such a memory model, based on Javas.
Schwartz is sencerely all for oepn source, and he insists he's not interested in sueing anyone over patents. They might sue over license infringement of course, but in this case there is none. It's all Apache code. The only sore point is that Android doesnt include a complete and compliant Java stack (neither JME or JSE), only a subset, so they wont be able to certify it as a compliant implementation, and therefore it's technically not 'the Java platform', it just looks alot like it. Google knows this, so they've been careful in their videos to only say 'written in the Java programming language'. Google and Sun are friends. This will be good for Java. Sun will no doubt provide some tooling support in NetBeans. I see no chance of any 'showdown' here.
I think thats a bit harsh. He didnt even use the term 'open source', he just said 'open' and clarified what he meant by it, which is that anyone can write software for it, which is true (contrast that to the pre-SDK iPhone). I think his concern is a valid one. You could imagine a malicious application on the phone that uses Bluetooth to detect other phones nearby and spam them with SMS messages or something. But I'm sure google's thought of this and there will be security mechanisms, permissions, signed applications with digital certificates etc. etc.
I'll confess I hadnt read the complete article at the time (hey its long! blame the rush to comment early) but I have since. The summary doesnt say that it wasnt a complete phone (a phone can also be a platform, which the iPhone + SDK will be, and the SavaJe built on the JavaFX platform). but I read the article and it turns out its not that. My comment was more of a reaction of suprise since I was expecting something iPhone like. There are already several platforms around. iPhone, Java ME (though its technology is now outgrowing it), OpenMoko, JavaFX, .NET Compact Framework. I wanted to see a device that was going to make me go 'wow'. But we'll have to wait and see what google's partners come up with.
So it's just a platform. I'm a little dissapointed. I think alot of us were waiting for a iPhone competitor. But so far it's just another linux and Java based software stack. What sets this platform apart form the rest?
So is it an actual product like an iPhone or JUST a platform like Java ME?
The default "cross platform" look and feel is indeed hideous, which is why most people would enable the native platform look and feel. The native platform look and feels were pretty bad in the past, but in Java 6 they're close to perfect, both on Windows and GTK. As for the cross platform look and feel, the Swing team have been working furiously to produce a modern replacement that will be available in a Java 6 update release early next year. It's called the Nimbus look and feel. Early screenshots available at http://www.galbraiths.org/blog/category/nimbus/ and http://www.jasperpotts.com/blog/category/nimbus/
Glassfish, Tomcat and Resin are all indepedant 100% pure Java webservers, all massively scalable and capable of processing 1000's of concurrent connections with performance comparable to Apache.
Yeah, I had a problem with that too. Because they added proprietary extensions that breached the specification (including Windows specific features), as well as omitting required features. Code written for the Microsoft VM wouldnt run on anyone elses. An implementation must be certified as compliant in order to use the Java brand. Microsoft's wasnt, so Sun sued. They won, and rightfully so.
But I'm glad this happened. It caused Microsoft to go off and create rival platform (.NET) and a rival language (C#). Maybe not so great for Sun, but great for the developer community, because it created good solid competition and both platforms are advancing at a rapid pace because of this.
For client Java developers like myself, the availability of the runtime is definitely the biggest challenges we face. Most computers do have a Java runtime installed, but few have the very latest, which is a shame because the last couple of releases have been MAJOR advances over 1.4 and earlier, which were admittedly pretty crappy for the client side. But Java 6 is excellent, but since it was only released in December, most people dont have it, and dont want to download even 7MB for it, and Java 7 is shaping up to be even more significant than Java 6. But I'm afraid, a native compiler wont solve the problem. You'd still need the libraries somewhere. So they'd still have to be installed previously, or include them with the application. Either way, there's downloading to be done. (though one of Java's major advantages is that once the platform IS installed, the actual applications tend to be remarkably small, because so much functionality is in the platform, and because of the amazing pack200 classfile compression). Plus, believe it or not, contrary to popular belief, an ahead-of-time native compiler would actually perform very poorly. The nature of the Java language depends on the runtime optimizations in order to achieve high performance. But that ends up being a good thing, because runtime optimzations allow it to optimize everything a C++ compiler can, and so much more. Still, Sun is well aware of the deployment problem. They have an entire team working to solve it in a future release targeted for early next year. Basically the initial download will be tiny (just a couple of MB) which contain the most common libraries, and the rest will be streamed in the background while the app is already running. Hopefully this will work out well. Early reports are promising. Deployment is a hard problem when your technology isnt bundled with the OS, but it is being worked on!
Fortunately the GNU Classpath guys are right on board with OpenJDK. One of their most prominent members Dalibor Topic (who's the lead on the Kaffe VM) is on the OpenJDK governence board and works with Sun and other representivies on managing the project. Other promiment members like Roman Kennke, David Gilbert, Mario Torre and others. are active on the OpenJDK mailing lists and submitting patches. They are all interested in becoming regular contributors to the project.
Other GNU Classpath developers working for Red Hat were very quick to produce a version of OpenJDK using pieces of Classpath to fill the wholes of "encumbered" components that havent been open sourced (like the font, graphics and sound engines that were licensed by Sun by 3rd parties). This is called IceTea. Though its more of a quick 'n dirty temporary project to have a completely GPL JDK right now until the holes can be plugged properly. For example, Sun released a more sophistated FreeType based font engine this week, and the rest of the holes will eventually be filled. But for now, IceTea is a great playground for experimentation. And as far as I can tell, Red Hat wants to contribute anything useful back in OpenJDK.
You might that the GNU Classpath guys would be dissapointed, feeling that their hard work is obsolete, but no, they're happy because they know they were a big part of the reason why OpenJDK exists, and they're looking forward to contributing.