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 -~----------~----~----~----~------~----~------~--~---
