RE: Sun JavaFx
Hi Stefano, Sorry for the delayed response been away for a few days. Yep will be very interesting to see how Sun commercializes the Savaje intellectual property they purchased from the liquidated assets. One of my clients www.Mexuar.com http://www.mexuar.com/ built a number of applications for the Savaje launch in SF 2006 so we are watching this recent announcement with anticipation. Will be an interesting few months to say the least. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] +1-212-203-4357 Ph +1-917-207-3420 Mb +61-2-9016-5642 (Sydney in-dial). http://click.mexuar.com/webuser/click/7/userurl/Cognation http://click.mexuar.com/webuser/nojs/7/userurl/Cognation -Original Message- From: [EMAIL PROTECTED] [mailto:community- [EMAIL PROTECTED] On Behalf Of Stefano Sanna Sent: Wednesday, 9 May 2007 1:01 AM To: community@lists.openmoko.org Subject: Re: Sun JavaFx Marco Miani wrote: Hi I've just read this http://www.sfgate.com/cgi-bin/blogs/sfgate/detail?blogid=19entry_id=163 10 about sun JavaFx and a mockup of a phone that will be presented soon WTF it's a Neo somebody knows something more ? I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). Cheers, Stefano. -- Stefano Sanna - [EMAIL PROTECTED] Personal web site: http://www.gerdavax.it AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community image001.gif___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
On 5/10/07, Jim Thompson [EMAIL PROTECTED] wrote: Terrence Barr - Evangelist, Java Mobile Embedded wrote: Shawn, I have been very involved in this area at Sun now for a couple of years. Let me add come comments: Hardware accelerated Java is actually fairly common already, at least in the Java ME space using ARM's Jazelle technology. It does have some benefits in very constrained platforms but in general advanced VMs with dynamic adaptive optimizations, compilation, and improved garbage collection perform better than H/W acceleration and at reasonable incremental cost (memory footprint, in particular). I think what we are seeing here is a general trend in the IT industry as general-purpose processors become more and more powerful they displace dedicated hardware solutions because software solutions are more flexible and lower cost. A notable exception, of course, is graphics acelleration but Java implementations typically use those when available. Specifically to Sun's Java chips (picoJava/microJava): I worked on them and the performance was quite good. But it is very hard, if not impossible, to keep up with performance improvements of general purpose processors together with the increasing amount of memory available. That technology evolution relegates Java hardware acceleration to niche status. Many companies have invested in Java H/W acceleration and fell into that trap. It turns out to be difficult to make Java go really fast on specialized hardware. Java wasn't designed to be fast, it was designed to be 'safe' Why is it so hard? What are the tough problems that are always going to be slow? What's wrong with taking some shortcuts, like the way KVM depends on pre-verified bytecodes so that it doesn't have to do the verification at load time? for large groups of programmers to use. You can get single order of magnitude speed-ups for some bytecode streams, but you won't see two. I (too) looked at doing a Java chip (very early, back in 1996 or so). Moore's law continues to march on, only now instead of (super)-linear speed-up on a single core, we're getting multiple cores. Java will be OK with 'multi-core', but won't survive the transition to 'manycore' ( 100 cores), nor will Python, PHP or Perl. This may not matter on a phone platform, but the desktop and server will distance themselves from co-operating sequential processes before too much longer. I think you are saying that the thread model of concurrency has limits, right? Or just that programmers will balk at having to manage hundreds of threads? Well what do you think is the future then, to get more parallelism? The only question is if the rest of the industry 'woke up' enough to see the light of cracking the phone wide-open. If not, they are doomed. Yeah that's a big one. I think Apple's view is that their applications are always best-of-breed anyway, and they can satisfy 90% of the users' needs themselves, so why be open to having third-party security holes, usability problems, bugs and so on, which will sully the reputation of the phone. But I also think a lot of the success of the early Palms was the wide variety of extra software you could install on them. I doubt that Apple will really keep the iPhone closed forever, but we'll see. Nowadays it's not like it was in the Palm era though... there are so many choices for development platform. Java, Brew, Windows Mobile, Palm, Symbian, Linux/QT, Linux/X, etc. Java has not been the unifying force that it should have been. I'm not very optimistic that is suddenly going to happen; the window has probably been missed. But I guess it's worth a try. If nothing else at least OpenMoko might be able to run Java games or something. I think one unsolved problem, which has probably hampered Java a lot, is the lack of a process model. If a Java VM was pre-loaded, and all of the Java applications could run in one VM, the overhead for each one would be much less, right? I know, I've heard the excuse... well, the OS is caching files anyway, each class's instructions are only being loaded once, and a separate VM increases security. But if a phone's top priority at bootup was to just to get all of the necessary classes into memory as fast as possible, and get the VM running, get the UI up and be ready to do the basic phone stuff (calls, phonebook etc.) maybe it could be fast. But Java has always been an adjuct. On the desktop, first you have all the overhead of the OS and its own UI, and then there is Java. Anytime I run a desktop Java app my reaction is ugh, you can always recognize a Java app by the startup time, the amount of memory it's taking up, and the paint idiosyncracies and the way the UI looks. And the installer typically put its own VM in place along with the app. So you will be running a different VM for every app. This is not a platform! And the phones I have worked with are just limited to one Java app at a time because they can't
Re: Sun JavaFx
Shawn, I'm more than happy to engage and debate these points, but its likely off-topic (or at least not in scope) for the list (which is about openmoko and/or the community that surrounds openmoko). Topics such as: why is Java slow (and how to construct hw to make it go fast concurrency models (threads or not) programming of same, and Java's lack of a process model aren't related (much) to openmoko, so I suggest we take these off-line, unless 'the list' decides they would rather watch/join the discussion here. (And yes, I agree that I contributed to the discussion going off-track.) The topic of Apple being open or closed, especially as it relates to the iPhone, seems at least peripheral to the discussion here. I think it likely to be mere months before some rudimentary linux kernel is running on the iPhone, and likley less than a year from then until some dedicated group of hackers make the OpenMoko environment run on the iPhone in much the same way that the Mac and the AppleTV, and even the iPod now run specialized linux kernels to 'enable' a degree of openness that Apple expressly did not plan. If OpenMoko is found to be a better environment than (or for) the iPhone (as well as other phones)... success!. If Sun's JavaFX Mobile, well... success! Jim Shawn Rutledge wrote: On 5/10/07, Jim Thompson [EMAIL PROTECTED] wrote: Terrence Barr - Evangelist, Java Mobile Embedded wrote: Shawn, I have been very involved in this area at Sun now for a couple of years. Let me add come comments: Hardware accelerated Java is actually fairly common already, at least in the Java ME space using ARM's Jazelle technology. It does have some benefits in very constrained platforms but in general advanced VMs with dynamic adaptive optimizations, compilation, and improved garbage collection perform better than H/W acceleration and at reasonable incremental cost (memory footprint, in particular). I think what we are seeing here is a general trend in the IT industry as general-purpose processors become more and more powerful they displace dedicated hardware solutions because software solutions are more flexible and lower cost. A notable exception, of course, is graphics acelleration but Java implementations typically use those when available. Specifically to Sun's Java chips (picoJava/microJava): I worked on them and the performance was quite good. But it is very hard, if not impossible, to keep up with performance improvements of general purpose processors together with the increasing amount of memory available. That technology evolution relegates Java hardware acceleration to niche status. Many companies have invested in Java H/W acceleration and fell into that trap. It turns out to be difficult to make Java go really fast on specialized hardware. Java wasn't designed to be fast, it was designed to be 'safe' Why is it so hard? What are the tough problems that are always going to be slow? What's wrong with taking some shortcuts, like the way KVM depends on pre-verified bytecodes so that it doesn't have to do the verification at load time? for large groups of programmers to use. You can get single order of magnitude speed-ups for some bytecode streams, but you won't see two. I (too) looked at doing a Java chip (very early, back in 1996 or so). Moore's law continues to march on, only now instead of (super)-linear speed-up on a single core, we're getting multiple cores. Java will be OK with 'multi-core', but won't survive the transition to 'manycore' ( 100 cores), nor will Python, PHP or Perl. This may not matter on a phone platform, but the desktop and server will distance themselves from co-operating sequential processes before too much longer. I think you are saying that the thread model of concurrency has limits, right? Or just that programmers will balk at having to manage hundreds of threads? Well what do you think is the future then, to get more parallelism? The only question is if the rest of the industry 'woke up' enough to see the light of cracking the phone wide-open. If not, they are doomed. Yeah that's a big one. I think Apple's view is that their applications are always best-of-breed anyway, and they can satisfy 90% of the users' needs themselves, so why be open to having third-party security holes, usability problems, bugs and so on, which will sully the reputation of the phone. But I also think a lot of the success of the early Palms was the wide variety of extra software you could install on them. I doubt that Apple will really keep the iPhone closed forever, but we'll see. Nowadays it's not like it was in the Palm era though... there are so many choices for development platform. Java, Brew, Windows Mobile, Palm, Symbian, Linux/QT, Linux/X, etc. Java has not been the unifying force that it should have been. I'm not very optimistic that is suddenly going to happen; the window has probably been missed. But I guess it's worth a try.
Re: Sun JavaFx
Jim Thompson writes: aren't related (much) to openmoko, so I suggest we take these off-line, unless 'the list' decides they would rather watch/join the discussion here. (And yes, I agree that I contributed to the discussion going off-track.) I for one have been interested (decades ago I was involved in special-purpose SIMD computers for computer vision, so I'm very familiar with watching Moore's Law overtake and bury specialized hardware!). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). That's correct. This is going to be very cool stuff. And the Neo is definitely very high on the list of devices I want to see this running on. If I understand correctly, JavaFX Script is going to be open source, but JavaFX Script is not the whole of the 'JavaFX family'. Does this mean there will be non-open sourced parts in the stack necessary to use JavaFX Script? ./Sander ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Sander van Grieken wrote: I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). That's correct. This is going to be very cool stuff. And the Neo is definitely very high on the list of devices I want to see this running on. If I understand correctly, JavaFX Script is going to be open source, but JavaFX Script is not the whole of the 'JavaFX family'. Does this mean there will be non-open sourced parts in the stack necessary to use JavaFX Script? Sun has already said that JavaFX Mobile (the stuff you need for the phone) will be GPLed. So.. no. Jim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Sander van Grieken wrote: I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). That's correct. This is going to be very cool stuff. And the Neo is definitely very high on the list of devices I want to see this running on. If I understand correctly, JavaFX Script is going to be open source, but JavaFX Script is not the whole of the 'JavaFX family'. Does this mean there will be non-open sourced parts in the stack necessary to use JavaFX Script? Sun has already said that JavaFX Mobile (the stuff you need for the phone) will be GPLed. So.. no. Well, this is not exactly true. Sun indeed said explicitly that JavaFX-Script will be GPLd, but regarding JavaFX-Mobile, I read the following : JavaFX Mobile, Sun's software system for mobile devices, is available via OEM license to carriers, handset manufacturers and others seeking a branded relationship with consumers source : http://www.sun.com/software/javafx/index.jsp ./Sander ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Sander van Grieken wrote: I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). That's correct. This is going to be very cool stuff. And the Neo is definitely very high on the list of devices I want to see this running on. If I understand correctly, JavaFX Script is going to be open source, but JavaFX Script is not the whole of the 'JavaFX family'. Does this mean there will be non-open sourced parts in the stack necessary to use JavaFX Script? Sun has already said that JavaFX Mobile (the stuff you need for the phone) will be GPLed. So.. no. Well, this is not exactly true. Sun indeed said explicitly that JavaFX-Script will be GPLd, but regarding JavaFX-Mobile, I read the following : JavaFX Mobile, Sun's software system for mobile devices, is available via OEM license to carriers, handset manufacturers and others seeking a branded relationship with consumers source : http://www.sun.com/software/javafx/index.jsp ./Sander ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Sander van Grieken wrote: Sander van Grieken wrote: I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). That's correct. This is going to be very cool stuff. And the Neo is definitely very high on the list of devices I want to see this running on. If I understand correctly, JavaFX Script is going to be open source, but JavaFX Script is not the whole of the 'JavaFX family'. Does this mean there will be non-open sourced parts in the stack necessary to use JavaFX Script? Sun has already said that JavaFX Mobile (the stuff you need for the phone) will be GPLed. So.. no. Ya know, I *knew* that if I didn't support the statement with URLs that someone would get it all wrong. Not you, Sander, (though receiving four copies of your message was a bit much), but the response from Gabriel kinda pissed in my Wheaties. Well, this is not exactly true. Sun indeed said explicitly that JavaFX-Script will be GPLd, but regarding JavaFX-Mobile, I read the following : JavaFX Mobile, Sun's software system for mobile devices, is available via OEM license to carriers, handset manufacturers and others seeking a branded relationship with consumers source : http://www.sun.com/software/javafx/index.jsp Of course it is, since Sun owns the Copyright, they can distribute non-GPL versions of the code to those who want them (and are willing to pay.) MySQL does this too. OTOH: Sun will ship a pre-integrated, GPL-licensable, Linux- and Java-based operating system software reference design for mobile phones, it announced at its JavaOne conference today in San Francisco. All JavaFX products will be available under the GNU GPL, Sun said. http://www.linuxdevices.com/news/NS7539760574.html --- Sun also announced that the company is planning on open sourcing JavaFX Script. We plan to open source all of JavaFX as we work through the program, said Green. The governance, license, and community models will be worked out as the company gets closer to delivering these products. Sun will release the source code of JavaFX Script to let other companies create web authoring tools using it. Sun, too, intends to create scripting tools for content authoring, Green said The alpha code that Sun demonstrated during Tuesday morning's general session is now available at the Project openjfx.org site. Sun will be enhancing and expanding this scripting language and encourages developers to join its community and send in feedback. http://java.sun.com/javaone/sf/2007/articles/tuesday_gs.jsp --- And you could have *AT LEAST* quoted the entire paragraph of the press release: http://www.sun.com/aboutsun/pr/2007-05/sunflash.20070508.1.xml The first of these, JavaFX Mobile, is a complete mobile phone software system available via OEM license to carriers, content owners and consumer electronics manufacturers. JavaFX leverages the security and ubiquity of the Java platform and will support all content and applications currently available across the billions of Java technology-based devices in the world today. Sun today also previewed JavaFX Script, a new scripting language targeted at creative professionals, which will help to radically simplify the process of creating and distributing interactive content that spans all Java technology enabled platforms, from handsets to set tops, laptops to dashboards (see separate announcement). ***All JavaFX software, like all Java software at Sun, will be available to the free and open source community via the popular GNU General Public License (GPL) license.*** (emphasis mine) Me, I think Java is a four-letter word (and I was @ Sun when it was invented), but I'm *certain* that Sun understands that it has made a commitment to commit all of its software technology to FOSS, and this includes new technologies. Or, you could listen to/watch the webcast where Rich Green is talking all about how they prefer the GPL and then segues into announcing that Java has been open sourced (under the GPL), Finally, Noel Poore and I used to work at Tadpole Technology, Plc together. (George Grey was the original Founder and CEO at both Tadpole and SavaJe.) If you don't know who Noel is, I suggest you check the SavaJe 'management' web page. Or my latest blog post: http://www.smallworks.com/archives/0489.htm (And yes, I did exchange email with Noel today.) Or you could continue to FUD. With the 20/20 hindsight of history, it turns out that ESR was wrong about many things, including being dead wrong about Sun. Sun *owns* the copyright to all of Java, and can offer it under a non-GPL license. Who might want to *pay* Sun for Free Software? Motorola, for one. Ed Zander (CEO of MOT, ex-COO of Sun) and McNeally (ex-CEO of Sun) golf together. Eric Schmidt (CEO of Google) used to work for McNeally and with Zander. If you *don't* think that the deal to get Java FX Mobile on MOT's handsets was done prior to this announcement, and you don't
Re: Sun JavaFx
I know its bad form to respond to one's own posting, but watch the end of the 'webcast' around the 15:00 mark, just after McNealy gets up to talk about Curriki, and then compares Rich Green to Jobs, where Jonathan Schwartz turns to ask Rich Green: JS: Rich, how would you feel about someone taking the JavaFX Mobile stack we just talked about and created an independent device, just took the code, paid Sun nothing, just created a $50 device or a $30 device? RG: To reach everyone? JS: Everyone RG: Perfect! Its just perfect. JS: So thats what we're trying to do, create an open platform that is truly open source... Apple just got its iPhone shoved into a dark, damp orifice. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Does this mean there will be non-open sourced parts in the stack necessary to use JavaFX Script? Sun has already said that JavaFX Mobile (the stuff you need for the phone) will be GPLed. So.. no. Well, this is not exactly true. Sun indeed said explicitly that JavaFX-Script will be GPLd, but regarding JavaFX-Mobile, I read the following : JavaFX Mobile, Sun's software system for mobile devices, is available via OEM license to carriers, handset manufacturers and others seeking a branded relationship with consumers source : http://www.sun.com/software/javafx/index.jsp Of course it is, since Sun owns the Copyright, they can distribute non-GPL versions of the code to those who want them (and are willing to pay.) MySQL does this too. OTOH: Sun will ship a pre-integrated, GPL-licensable, Linux- and Java-based operating system software reference design for mobile phones, it announced at its JavaOne conference today in San Francisco. All JavaFX products will be available under the GNU GPL, Sun said. http://www.linuxdevices.com/news/NS7539760574.html Excellent, this is very reassuring. I did some searching, but didn't find any explicit statements regarding the whole FX stack, but this definately answers my question. And you could have *AT LEAST* quoted the entire paragraph of the press release: http://www.sun.com/aboutsun/pr/2007-05/sunflash.20070508.1.xml I didn't quote the press release but the JavaFX product page. Since GPLing the stack is a selling point (at least, from my perspective), Sun should mention that right there. However, thanks for pointing me to the press release. It makes the issue very clear. Me, I think Java is a four-letter word yeah, it means Just Another Vague Acronym, right? :) Or, you could listen to/watch the webcast where Rich Green is talking all about how they prefer the GPL and then segues into announcing that Java has been open sourced (under the GPL), being a developer, I kinda hate ambiguity. I interpreted this as 'the VM/JDK has been open sourced'. That doesn't necessarily mean technologies on top of that are open sourced. Or you could continue to FUD. With the 20/20 hindsight of history, it turns out that ESR was wrong about many things, including being dead wrong about Sun. well it was not my intention to spread FUD, but since this is the Openmoko mailing list, it should be very clear what the degree of openness is. ./Sander ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Shawn, I have been very involved in this area at Sun now for a couple of years. Let me add come comments: Hardware accelerated Java is actually fairly common already, at least in the Java ME space using ARM's Jazelle technology. It does have some benefits in very constrained platforms but in general advanced VMs with dynamic adaptive optimizations, compilation, and improved garbage collection perform better than H/W acceleration and at reasonable incremental cost (memory footprint, in particular). I think what we are seeing here is a general trend in the IT industry as general-purpose processors become more and more powerful they displace dedicated hardware solutions because software solutions are more flexible and lower cost. A notable exception, of course, is graphics acelleration but Java implementations typically use those when available. Specifically to Sun's Java chips (picoJava/microJava): I worked on them and the performance was quite good. But it is very hard, if not impossible, to keep up with performance improvements of general purpose processors together with the increasing amount of memory available. That technology evolution relegates Java hardware acceleration to niche status. Many companies have invested in Java H/W acceleration and fell into that trap. As for the comparison of JavaFX Mobile with the iPhone: Sure, at first it looks like a me too play, but I think this applies to the whole mobile industry. The iPhone was a major wake-up call to the industry and so I think you will see many iPhone knock-offs over the next 18 months simply because the iPhone is leading the way. However, JavaFX Mobile is distinctly different in that it will be an open system (not closed as the iPhone) and will be part of a multi-screen approach that delivers content across desktops, TV, and mobile. Only Java currently has that market reach so Sun would be ill-advised *not* to capitalize that. Cheers, -- Terrence Shawn Rutledge wrote: I'm very disappointed that Sun has put off hardware-accelerated Java devices and Java operating systems for so long (they could have done this at least 5 years ago, if not more). The much-vaunted Java Chips never materialized in significant quantities of devices. The Java Station had such disappointing performance (and why? it could have been much better). And now just because the iPhone is coming out Sun suddenly decided to present an impression of being on the ball. Coming out now, it just looks like a lame me too play. Of course its performance probably still sucks... it will be a pleasant and unexpected surprise if not. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community begin:vcard fn:Terrence Barr n:Barr;Terrence org:Sun Microsystems adr:;;Zettachring 10 A;Stuttgart;;70587;Germany email;internet:[EMAIL PROTECTED] title:Evangelist, Java Mobile Embedded Community tel;work:+49 711 720 98185 url:http://www.mobileandembedded.com version:2.1 end:vcard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Terrence Barr - Evangelist, Java Mobile Embedded wrote: Shawn, I have been very involved in this area at Sun now for a couple of years. Let me add come comments: Hardware accelerated Java is actually fairly common already, at least in the Java ME space using ARM's Jazelle technology. It does have some benefits in very constrained platforms but in general advanced VMs with dynamic adaptive optimizations, compilation, and improved garbage collection perform better than H/W acceleration and at reasonable incremental cost (memory footprint, in particular). I think what we are seeing here is a general trend in the IT industry as general-purpose processors become more and more powerful they displace dedicated hardware solutions because software solutions are more flexible and lower cost. A notable exception, of course, is graphics acelleration but Java implementations typically use those when available. Specifically to Sun's Java chips (picoJava/microJava): I worked on them and the performance was quite good. But it is very hard, if not impossible, to keep up with performance improvements of general purpose processors together with the increasing amount of memory available. That technology evolution relegates Java hardware acceleration to niche status. Many companies have invested in Java H/W acceleration and fell into that trap. It turns out to be difficult to make Java go really fast on specialized hardware. Java wasn't designed to be fast, it was designed to be 'safe' for large groups of programmers to use. You can get single order of magnitude speed-ups for some bytecode streams, but you won't see two. I (too) looked at doing a Java chip (very early, back in 1996 or so). Moore's law continues to march on, only now instead of (super)-linear speed-up on a single core, we're getting multiple cores. Java will be OK with 'multi-core', but won't survive the transition to 'manycore' ( 100 cores), nor will Python, PHP or Perl. This may not matter on a phone platform, but the desktop and server will distance themselves from co-operating sequential processes before too much longer. As for the comparison of JavaFX Mobile with the iPhone: Sure, at first it looks like a me too play, but I think this applies to the whole mobile industry. The iPhone was a major wake-up call to the industry and so I think you will see many iPhone knock-offs over the next 18 months simply because the iPhone is leading the way. The only question is if the rest of the industry 'woke up' enough to see the light of cracking the phone wide-open. If not, they are doomed. Bill Joy explained it a long time ago. Lemma 1: # smart employees = log(# of employees) -- there are more smart people outside your organization than inside it Lemma 2: Innovation will occur Lemma 1 tells us that it will occur elsewhere. Question: How do you take advantage of innovation that occurs outside the organization? Answer: Open Source Of course, FOSS is one answer, there are others, but stating the answer without knowing the question is Jeopardy! However, JavaFX Mobile is distinctly different in that it will be an open system (not closed as the iPhone) and will be part of a multi-screen approach that delivers content across desktops, TV, and mobile. Only Java currently has that market reach so Sun would be ill-advised *not* to capitalize that. Even then, Java, even JavaFX is not the web. http://shaver.off.net/diary/2007/05/10/the-high-cost-of-some-free-tools/ Jim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
2007/5/8, Vincent [EMAIL PROTECTED]: On 08/05/07, Marco Miani [EMAIL PROTECTED] wrote: Hi I've just read this http://www.sfgate.com/cgi-bin/blogs/sfgate/detail?blogid=19entry_id=16310 about sun JavaFx and a mockup of a phone that will be presented soon WTF it's a Neo Now that's funny... But as the text says: even as he released a photo of a mockup (left) And: We're not introducing a phone. We're introducing software to make this possible. So I suppose they just made a screenshot of the software and pasted it onto a picture of the Neo1973... Nice! As it said here[1] it is real: What is it? It's a phone running Sun's new JavaFX Mobile software, a member of the JavaFX product family we announced this morning [1] http://blogs.sun.com/jonathan/entry/when_not_where -- J. Manrique López de la Fuente http://www.jsmanrique.net msn: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Stefano Sanna wrote: Marco Miani wrote: Hi I've just read this http://www.sfgate.com/cgi-bin/blogs/sfgate/detail?blogid=19entry_id=16310 about sun JavaFx and a mockup of a phone that will be presented soon WTF it's a Neo somebody knows something more ? I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). That's correct. This is going to be very cool stuff. And the Neo is definitely very high on the list of devices I want to see this running on. -- Terrence Cheers, Stefano. -- Terrence Barr Technical Evangelist, Java Mobile Embedded Community Phone: +49 711 720 98185 http://www.mobileandembedded.org, http://www.sun.de, http://www.sun.com Registered Office: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten, Germany Commercial register of the Local Court of Munich: HRB 161028 Managing Directors: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer Chairman of the Supervisory Board: Martin Haering NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. begin:vcard fn:Terrence Barr n:Barr;Terrence org:Sun Microsystems adr:;;Zettachring 10 A;Stuttgart;;70587;Germany email;internet:[EMAIL PROTECTED] title:Evangelist, Java Mobile Embedded Community tel;work:+49 711 720 98185 url:http://www.mobileandembedded.com version:2.1 end:vcard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Marco Miani wrote: Hi I've just read this http://www.sfgate.com/cgi-bin/blogs/sfgate/detail?blogid=19entry_id=16310 about sun JavaFx and a mockup of a phone that will be presented soon WTF it's a Neo somebody knows something more ? I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). Cheers, Stefano. -- Stefano Sanna - [EMAIL PROTECTED] Personal web site: http://www.gerdavax.it AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
