The article mostly agrees with what Drew said with very few exceptions. The article points at Asha devices (and other devices) that have very small amounts of memory (2mb) and yet perform really well with a GC (and a slow CPU). The GC study pointed in the Drew article was a desktop study taken out of context.
It says that JavaScript is inherently slow because of DOM. It says that this should not be applied as a sweeping generalization to all managed languages e.g. Java. Then it gives examples including mobile Java performance where small heap devices work just fine.
The separation is useful to understand where the optimization is necessary. JavaScript could be made less painful if it didn't have DOM manipulation to contend with obviously that's not very practical.
Come on... I have the word XYZ and search for XY it won't find it. Won't let me sort search results or apply really elaborate search filters beyond by date. If I have an attachment and a vague recollection of the email its about as good as gone, I have to remember the exact spelling used within the email.
If it was another company I would let sleeping dogs lie but this is f'ing Google. Their web search is SOOO good and improving all the time, that makes the gmail search so ridiculously outdated in comparison. Their recent changes to search just added more information but didn't actually solve the core problem of "it doesn't work...".
Despite the comments who pick on the Iacocca example (not familiar with that) Schmidt is remarkably technical for a CEO (former Sun CTO with a T) which is really rare. TOR was not something that would be interesting to him, they are doing big data, search mobile and many other things that he needs to understand. TOR would be just general knowledge for a guy who does more than most of us do every day.
They aren't stupid, they understand that terrorism works. E.g. in Israel we had a peace process that was going relatively well between the left wing and the PLO. So the Hamas started blowing up buses and the peace process died. Hamas which was marginalized before used that collapse (and rise of Israeli right wing that resulted) to take over Gaza strip after the fact. So terrorists can come from a very weak position and manipulate public opinion very effectively. E.g. before 911 no one cared much about Bin Laden, now the "arab spring" is turning into religious governments who shape more after Iran than after the USA... As engineers they are remarkably effective at manipulating us (or really the dumber element of our society)
The main issues with FX are the same as those people have with ActionScript. The language is reasonable as a scripting language to tie things together but it feels very odd for most Java developers. Unlike action script you don't get the advantage of the amazing GUI tools Adobe offers.
Web start seems simple when creating hello world, NetBeans gets you started with a self signed JWS version. For production you will need a proper certificate which is harder but doable. Then there is the issue of pack.gz with its odd special case servlet (don't get me started on that one). Then you have the issues of HTTPs deployments not working for some people and the multiple incompatibilities between JWS versions installed which occur when someone has a corporate PC with a specific version of Java installed. There are lots of issues some summed up here for older versions: http://www.jroller.com/vprise/entry/should_you_use_jws
Newer versions of JWS (Java 6u10) broke different things but didn't really fix lots of the long standing issues. Most people using JWS just got burned one time too many.
Since no one is using or interested in FX what you are saying is far more unlikely.
FX has damaged Java's existing client side developers (yes there were many) by pulling funding from many important tasks such as the native look and feels which still don't work properly.
Its publicly despised by most Java developers who tried working with it and designers who compare it to Flash are just shocked that something as godawful as this would be released as a "Flash competitor".
Please actually try a technology before buying into the marketing nonsense that Sun has been spewing on FX. Our team did try this to produce demos and we were shocked at how horrible it was (I am talking production 1.0 and 1.1 versions!).
Another poster who never actually seriously tried FX!
We are serious Java and Flash experts and we spent a considerable amount of time with a direct line to the FX developers... Everything we were able to produce was just terrible. Migrating skills from Java to FX is an exercise in futility, developers who had no Java experience had an advantage there. All us Java geeks were cursing the backwards way of doing things and the oddities, the IDE is ridiculous the live preview doesn't work and there is no way to visually build anything. Sure you can import really simple SVG graphics (not the elaborate stuff) but no animations and you need to start maintaining it in FX otherwise if node name changes well...
Communicating with the server, don't make me laugh! Did you try serializing an FX object to a server? We were better off using plain Applets or even web start both of which now suck more because Sun spent so much energy on FX and botched the quality of Java 6u10. Just read the Java developer forums where everyone is cursing FX. Other than Sun employee/contractors or people who didn't actually try FX no one is excited by this nonsense. Did you see the flashy demos, did you actually dig into the source code to see that most of them just use bitmap graphics for all the flashy animations???
Don't get me started on how ridiculous the mobile version of FX is.
You obviously never tried deploying a web start application. If it works then great its a wonderful thing, problem is that the simple idea is botched horribly on many machines due to multiple VM versions with incompatible web start revisions etc. There are some cases where you just can't figure out the problem. I defended and advocated JWS for years but Sun just can't get it right even with the huge investment for Java 6u10 JWS is still broken for many applications (not to mention breaking the native look and feel so badly that all sorted tables no longer work!).
BTW This is largely FX's fault which caused Sun to essentially move all non-fx development to maintenance mode.
Just finished the book too and loved it (same for both of his previous books). The book does say that you can succeed by your own merit but the *scale* of your success depends on your "history" or ancestry. Personally my favorite part was the last chapter about Daisy which I found personal and very touching.
I assume you are more familiar with LGPL than I am. However, I don't think this violates the intent of GPL (at least not more than the LGPL license) since the license was approved by RMS (it is the one used for open sourcing Java SE).
No there isn't. LGPL requires opening the application source code when linking with the library. The interpretation of the word linking has been widely debated... The classpath exception does not. Sun representatives have stated that the goal is to allow proprietary development with the library e.g.: http://weblogs.java.net/blog/terrencebarr/
The classpath exception is a different use case from LGPL which doesn't make sense in the mobile world where dynamic libraries can't be deployed (in most phones). Its designed to allow proprietary applications but requires changes to LWUIT to be contributed back: http://lwuit.blogspot.com/2008/05/licensing-terms-of-lwuit.html http://lwuit.blogspot.com/2008/08/lwuit-open-source-today-plus-great-new.html
It has the classpath exception: http://lwuit.blogspot.com/2008/08/lwuit-open-source-today-plus-great-new.html http://lwuit.blogspot.com/2008/05/licensing-terms-of-lwuit.html
Its not a UI project, its a UI library designed by and for programmers with demos designed to explain details for programmers. If you assume Sun has UI designers on payroll you obviously haven't used Sun products;-) Relatively to Sun this is pretty good and since its free software that gives power to the programmers which is more than most other mass market solutions.
Well LWUIT could use the iPhone theme but then Sun would get sued. No point in deriding a technical project on the lack of a full time UI designer... The text in the 3D cube in newer versions of LWUIT is anti-aliased, its still not as smooth as it can be but it runs on pretty much every phone out there. Furthermore, it will look better with newer devices while still supporting existing 50$ phones.
Plasma, iPhone, Android etc. are all great but LWUIT runs today on a billion shipping phones... I doubt any of the above would ever make that number.
See some of the newer demos and videos here: http://lwuit.blogspot.com/
Slashdot Mirror
The article mostly agrees with what Drew said with very few exceptions. The article points at Asha devices (and other devices) that have very small amounts of memory (2mb) and yet perform really well with a GC (and a slow CPU).
The GC study pointed in the Drew article was a desktop study taken out of context.
It says that JavaScript is inherently slow because of DOM. It says that this should not be applied as a sweeping generalization to all managed languages e.g. Java. Then it gives examples including mobile Java performance where small heap devices work just fine.
Most j2me devices didn't use code from Sun.
It's not a rebuttle, in fact he didn't refute any claim other than the GC article. Read the comments where game programming is also discussed.
The separation is useful to understand where the optimization is necessary. JavaScript could be made less painful if it didn't have DOM manipulation to contend with obviously that's not very practical.
Come on... I have the word XYZ and search for XY it won't find it. Won't let me sort search results or apply really elaborate search filters beyond by date.
If I have an attachment and a vague recollection of the email its about as good as gone, I have to remember the exact spelling used within the email.
If it was another company I would let sleeping dogs lie but this is f'ing Google. Their web search is SOOO good and improving all the time, that makes the gmail search so ridiculously outdated in comparison. Their recent changes to search just added more information but didn't actually solve the core problem of "it doesn't work...".
Despite the comments who pick on the Iacocca example (not familiar with that) Schmidt is remarkably technical for a CEO (former Sun CTO with a T) which is really rare. TOR was not something that would be interesting to him, they are doing big data, search mobile and many other things that he needs to understand. TOR would be just general knowledge for a guy who does more than most of us do every day.
They aren't stupid, they understand that terrorism works. E.g. in Israel we had a peace process that was going relatively well between the left wing and the PLO. So the Hamas started blowing up buses and the peace process died. Hamas which was marginalized before used that collapse (and rise of Israeli right wing that resulted) to take over Gaza strip after the fact.
So terrorists can come from a very weak position and manipulate public opinion very effectively. E.g. before 911 no one cared much about Bin Laden, now the "arab spring" is turning into religious governments who shape more after Iran than after the USA... As engineers they are remarkably effective at manipulating us (or really the dumber element of our society)
So the result for this would be a failure due to no index. Ugh. BigTable.
The main issues with FX are the same as those people have with ActionScript. The language is reasonable as a scripting language to tie things together but it feels very odd for most Java developers. Unlike action script you don't get the advantage of the amazing GUI tools Adobe offers.
Web start seems simple when creating hello world, NetBeans gets you started with a self signed JWS version. For production you will need a proper certificate which is harder but doable. Then there is the issue of pack.gz with its odd special case servlet (don't get me started on that one). Then you have the issues of HTTPs deployments not working for some people and the multiple incompatibilities between JWS versions installed which occur when someone has a corporate PC with a specific version of Java installed.
There are lots of issues some summed up here for older versions:
http://www.jroller.com/vprise/entry/should_you_use_jws
Newer versions of JWS (Java 6u10) broke different things but didn't really fix lots of the long standing issues. Most people using JWS just got burned one time too many.
Since no one is using or interested in FX what you are saying is far more unlikely.
FX has damaged Java's existing client side developers (yes there were many) by pulling funding from many important tasks such as the native look and feels which still don't work properly.
Its publicly despised by most Java developers who tried working with it and designers who compare it to Flash are just shocked that something as godawful as this would be released as a "Flash competitor".
Please actually try a technology before buying into the marketing nonsense that Sun has been spewing on FX. Our team did try this to produce demos and we were shocked at how horrible it was (I am talking production 1.0 and 1.1 versions!).
Another poster who never actually seriously tried FX!
We are serious Java and Flash experts and we spent a considerable amount of time with a direct line to the FX developers... Everything we were able to produce was just terrible.
Migrating skills from Java to FX is an exercise in futility, developers who had no Java experience had an advantage there. All us Java geeks were cursing the backwards way of doing things and the oddities, the IDE is ridiculous the live preview doesn't work and there is no way to visually build anything. Sure you can import really simple SVG graphics (not the elaborate stuff) but no animations and you need to start maintaining it in FX otherwise if node name changes well...
Communicating with the server, don't make me laugh! Did you try serializing an FX object to a server?
We were better off using plain Applets or even web start both of which now suck more because Sun spent so much energy on FX and botched the quality of Java 6u10.
Just read the Java developer forums where everyone is cursing FX. Other than Sun employee/contractors or people who didn't actually try FX no one is excited by this nonsense. Did you see the flashy demos, did you actually dig into the source code to see that most of them just use bitmap graphics for all the flashy animations???
Don't get me started on how ridiculous the mobile version of FX is.
You obviously never tried deploying a web start application. If it works then great its a wonderful thing, problem is that the simple idea is botched horribly on many machines due to multiple VM versions with incompatible web start revisions etc. There are some cases where you just can't figure out the problem. I defended and advocated JWS for years but Sun just can't get it right even with the huge investment for Java 6u10 JWS is still broken for many applications (not to mention breaking the native look and feel so badly that all sorted tables no longer work!).
BTW This is largely FX's fault which caused Sun to essentially move all non-fx development to maintenance mode.
Just finished the book too and loved it (same for both of his previous books). The book does say that you can succeed by your own merit but the *scale* of your success depends on your "history" or ancestry.
Personally my favorite part was the last chapter about Daisy which I found personal and very touching.
I assume you are more familiar with LGPL than I am. However, I don't think this violates the intent of GPL (at least not more than the LGPL license) since the license was approved by RMS (it is the one used for open sourcing Java SE).
That is my understanding of the license (IANAL):
http://en.wikipedia.org/wiki/GPL_linking_exception
Section 4.d.1 seems to be relevant:
http://www.gnu.org/licenses/lgpl.html
No there isn't.
LGPL requires opening the application source code when linking with the library. The interpretation of the word linking has been widely debated... The classpath exception does not. Sun representatives have stated that the goal is to allow proprietary development with the library e.g.:
http://weblogs.java.net/blog/terrencebarr/
The classpath exception is a different use case from LGPL which doesn't make sense in the mobile world where dynamic libraries can't be deployed (in most phones).
Its designed to allow proprietary applications but requires changes to LWUIT to be contributed back: http://lwuit.blogspot.com/2008/05/licensing-terms-of-lwuit.html
http://lwuit.blogspot.com/2008/08/lwuit-open-source-today-plus-great-new.html
It has the classpath exception:
http://lwuit.blogspot.com/2008/08/lwuit-open-source-today-plus-great-new.html
http://lwuit.blogspot.com/2008/05/licensing-terms-of-lwuit.html
Check the SVN: https://lwuit.dev.java.net/source/browse/lwuit/
Its not a UI project, its a UI library designed by and for programmers with demos designed to explain details for programmers. If you assume Sun has UI designers on payroll you obviously haven't used Sun products ;-)
Relatively to Sun this is pretty good and since its free software that gives power to the programmers which is more than most other mass market solutions.
Well LWUIT could use the iPhone theme but then Sun would get sued. No point in deriding a technical project on the lack of a full time UI designer...
The text in the 3D cube in newer versions of LWUIT is anti-aliased, its still not as smooth as it can be but it runs on pretty much every phone out there.
Furthermore, it will look better with newer devices while still supporting existing 50$ phones.
Plasma, iPhone, Android etc. are all great but LWUIT runs today on a billion shipping phones... I doubt any of the above would ever make that number.
See some of the newer demos and videos here:
http://lwuit.blogspot.com/