Absolutely. User experience is our top priority right now. You will see continual improvements throughout this year.
On Feb 27, 2009, at 2:48 AM, Christian Hvid wrote: > > You guys are starting with the wrong problem. > > Development tools, language, frameworks doesn't really matter. > > It is whether it works at the end-user. > > How fast it loads, whether there are obscure security dialogs, whether > graphics flashes and flickers ... > > Solve that and you will have users and developers en masse. > > On Feb 23, 6:06 pm, Joshua Marinacci <[email protected]> wrote: >> Hi Karsten. This is Josh from Sun. >> >> You are correct that JavaFX is not as mature as Flex and Sliverlight. >> This is simply because it is newer. When comparing JavaFX to these >> other toolsets please keep that in mind. JavaFX 1.0 was released only >> about 3 months ago. But we are working very hard to improve and >> expand >> JavaFX very quickly. We've already had one update release and another >> is planned for around the JavaOne timeframe. >> >> JavaFX's strengths: though JavaFX is behind Flex & Silverlight in >> several ways (notably designer tools and components), JavaFX has some >> distinct advantages over the competition. >> >> First, it is built on the powerful and mature JVM letting you drop >> down to Java code at any time. This means you get all of the great >> things the JVM provides for free. It is the fastest client technology >> available for compute intensive applications. It has robust multi- >> threaded computing support. And you can access the rich ecosystem of >> existing Java libraries out there (millions of lines of open source >> Java code). >> >> Now I understand that talking to bluetooth isn't a compelling feature >> for your enterprise application. But what if you have validation code >> on your server. Why write that again in a different language on the >> client when you could just share the jars directly between client and >> server. Webservices? Why write new webservices marshalling code when >> you can use the great SOAP, RMI, and REST apis which already exist. >> What if you need to recompute some charts using special scientific >> algorithms that are on your server. Just reuse it directly on the >> client. No rewriting is necessary. And for games (a growing part of >> the RIA market), access to existing physics and game controller >> libraries is wonderful. >> >> Second, JavaFX is multi-screen. JavaFX runs on both desktop and >> mobile >> devices, and eventually TVs as well. And I don't mean that you can >> use >> one language to write two apps, like you can today with Java. I mean >> literally the same code can run in both places unmodified, with your >> application adapting itself to the UI constraints of that device. >> JavaFX gives you one download with one language, SDK, and set of >> APIs, >> for all of the screens. That's something that doesn't exist anywhere >> else. I'm a complete JavaME novice but I've been able to easily >> write >> mobile apps with JavaFX. >> >> Components: JavaFX currently has only the TextBox component. You can >> use any Swing component in your application, however, even ones we >> haven't provided wrappers for. This lets you mix and match between >> existing Swing code and new JavaFX code. In addition, we are >> planning >> a full set of new components which will work on both desktop and >> mobile (Swing is desktop only), and will be CSS skinnable, support >> shaped and translucent boundaries, transitions, and all of the other >> things you expect from 21st century GUI components. >> >> I hope this addresses your concerns and I hope you will continue to >> watch JavaFX as it improves over the coming months. >> >> Thanks, >> Josh >> >> On Feb 20, 2009, at 5:05 AM, Karsten Silz wrote: >> >> >> >> >> >>> In episode 230 the JavaFX team was asked about why Flash/Flex/ >>> Silverlight developer/designers should look at JavaFX. The answer >>> was >>> that it allows them to tap into the Java ecosystem, with accessing >>> Bluetooth and the accelerometer on the MAC as examples. >> >>> I work for a company that uses both Java and Flex in their >>> enterprise >>> products. From this perspective, the answer really left me >>> scratching >>> my head: >> >>> Firstly, Flash/Flex/Silverlight run in a browser, accessing a >>> Java / .NET / PHP / Python / Ruby / whatever back-end. So I think >>> they all can tap into the biggest piece of the Java ecosystem just >>> fine - the one that runs on the server (and the server parts of all >>> the other ecosystems, too). >> >>> Secondly, how many Flash/Flex/Silverlight get enhanced because they >>> know you shake your MAC? That's right, not a whole lot. >>> Bluetooth is >>> more interesting, but as an app in the browser accessing Bluetooth, >>> you'll face several hurdles: Enterprise laptops are often locked >>> down >>> beyond belief (no app installation, no WiFi, no USB, no Bluetooth), >>> the app probably has to ask for your permission, and the anti-virus >>> software will light up like a Christmas tree when the browser >>> accesses >>> the mobile phone. With the last two points you'll probably lose >>> your >>> mom in the "Could my mom do that on her computer?" test. Anyway, I >>> believe only a small amount of existing Flash/Flex/Silverlight apps >>> would benefit from these Java advantages. >> >>> Finally, if you want to get nitpicky: If you use Bluetooth to access >>> data on your mobile phone, I would argue you're moving in the wrong >>> direction. For email/calendar/contacts/notes/tasks/files, the world >>> seems to move to "web app plus mobile apps" scenario, often combined >>> with a desktop app, with the data residing in the cloud. Examples: >>> Apple's Mobile Me (http://www.apple.com/mobileme/) and Microsoft's >>> upcoming Live Mesh (https://www.mesh.com/Welcome/overview/ >>> overview.aspx) and My Phone (http://www.twice.com/article/ >>> CA6637868.html). I think I also read that the Google phone G1 >>> doesn't >>> even have a desktop syncing app anymore, and the upcoming Palm Pre >>> isn't supposed to have one, either. >> >>> Now coming back to Flex. We really like it in our Struts Java apps, >>> and we want to go full Flex as soon as possible (though we'll >>> probably >>> need an HTML client for smartphones). Our products are monitoring >>> systems for IP-based devices (currently tens of thousands of them), >>> deployed in corporate intranets. Here are what I can see as the >>> advantages Flex 3 has over JavaFX 1.1: >> >>> - Ubiquity. We never had a problem with any of our customers not >>> being >>> able to use Flash. >> >>> - Charts. That is the killer feature for Flex in the enterprise in >>> my >>> opinion, and it's what brought us to Flex us. Look at >>> http://examples.adobe.com/flex2/inproduct/sdk/dashboard/dashboard.html >>> In the pie chart, mouse over the pieces and select a piece - it >>> looks >>> nice, is nicely animated and gives you the necessary information. >>> It's also linked to the table below, allowing you to drill in, and >>> you >>> can mouse over the data points there, too. Finally, use the sliders >>> at the top to change the timeline. Now look at at this dashboard: >>> http://examples.adobe.com/flex3/devnet/dashboard/main.html Click on >>> the pie pieces at the top right and see how it drills into the >>> details >>> for a region, and click again to go back. Same with the bar chart >>> in >>> the top middle - click a month to see the breakdown by day. In our >>> application, we allow the user to zoom in on a chart by drawing a >>> rectangle with their mouse. To sum it up: You get nice looking >>> charts >>> with good information, natural navigation, and little load on the >>> server (you only transfer the data to the client and don't generate >>> any images). We're not the only ones, apparently - two of the few >>> UI >>> component changes in Flex 3 were a tree data grid and and OLAP data >>> grid. >> >>> - AMF3 & BlazeDS: When you transmit tends of thousands of records to >>> the client, XML over HTTP or JSON use too much bandwidth and too >>> much >>> CPU time marshalling / unmarshalling data. We found that Adobe's >>> binary AMF3 protocol is the fastest way to send data to a Flex >>> client; >>> Adobe published the spec a while ago (http:// >>> www.rooftopsolutions.nl/ >>> article/169). We use it together with Adobe BlazeDS, an open source >>> project by Adobe. I'm not an expert on this, but I think it >>> allows us >>> to rather easily take Java objects, send them across the wire with >>> AMF3 and have them come out as native ActionScript objects in the >>> Flex >>> client on the other side. You also get "publish and subscribe" >>> messaging through BlazeDS (though under the hood, the clients still >>> poll in configurable intervals). Adobe recently added AMF3 >>> support to >>> PHP (http://blogs.adobe.com/flex/archives/2008/07/ >>> adobe_contributing_amf_support.html) and works with SpringSource on >>> BlazeDS integration (http://www.theregister.co.uk/2008/12/09/ >>> springsource_adobe/print.html). Curl, a nice RIA player, recently >>> started supporting AMF3, too (http://www.curl.com/ >>> company_news010609.php). >> >>> Here are some things I'm not sure if JavaFX can do that: >> >>> - Data Grid: The Flex data grid allows for search, sorting and >>> column- >>> rearranging through drag'n drop on the client, and it handles tens >>> of >>> thousands of records easily. >> >>> - Components: There are lots of open source and commercial Flex >>> components. We use some open source ones, and we have a commercial >>> component for mapping. >> >>> - Ease of use: Our developers repeatedly commented on how much >>> easier >>> it is to create a Flex UI than with Struts (granted, Struts is quite >>> dated). From what I hear, it's events, data binding and UI states >>> that are responsible for this. >> >>> - Flex Builder: It is rather weak compared to the Eclipse Java >>> tools, >>> but it has a debugger and a visual UI builder. There seems to be >>> only >>> one visual JavaFX builder, but I don't know whether the JFXBuilder >>> runs on Eclipse (http://www.reportmill.com/jfx/). >> >>> So if JavaFX gave me all of the above, it still would only be on par >>> with Flex, so giving us no good business reason to switch. And >>> then, >>> Flex isn't standing still - with the upcoming Flex 4, the component >>> model will be revamped, Flex Builder will improve, and integration >>> with the rest of the Adobe tools (we use Photoshop and Fireworks) >>> will >>> get tighter. >> >>> But maybe I'm missing a lot about JavaFX. So, why should we switch >>> from Flex to JavaFX? > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
