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