No JavaFX for iOS, Android or WP - why not?

Freddy Guime freddy at
Tue Oct 9 18:33:08 PDT 2012

Interesting observations, in this sense I can relate. I am a Swing developer
for an Options Trading Platform here in Chicago, and coming from JavaOne one
of my goals was to evaluate the appropriateness of JavaFX to replace our
front-end Swing App.

For the lack of CSS I agree with Mark. In the realm of Desktop application,
while it is definitively a 'nice' feature is not that we 'tinker' with a
Swing App skin all day long, and while sometimes painful (Nimbus, I'm
looking at you :P) it is probably where we spend the least time in Swing

In terms of components, (and I love the components done by Gerrit, and
appreciate the work done by Jonathan Giles), I think we are still 'in
development'. What I am realizing is that probably, the basics are there,
and there seems to be enough 'hooks' and extensibility to fill-in the gaps.
We are trying, under-the-covers do a pilot and see how a particular (but yet
very important) section of our system behaves under JavaFX. Questions on
performance (Options Exchanges sends a lot of Market Data, which required us
to tweak JTables immensely, so I'm expected that will happen in FX) and
adequacy for our 'financial' app will be answered then. 

In that sense, it does feel that for us, the Desktop guys (probably a
minority nowadays) would have to eventually move away from Swing, as it is
going to become 'stale' (Evidenced by not having a single session on Swing
at this JavaOne, nor a lot of Swing bugs being closed, kinda expected, but
still). One risk that I do see is that because Swing developers will have to
move/migrate to another technology, a question of alternative technologies
is brought up (even for us, sadly looking at WPF + C# as well) 

Just adding my 2c as a rogue Desktop Developer :)

Freddy Guime


Date: Tue, 9 Oct 2012 14:47:07 -0700
From: Mark Fortner <phidias51 at>
Subject: Re: Re: No JavaFX for iOS, Android or WP - why not?
To: openjfx-dev at
	<CAOwy01uuCvJZs94yzR2DVU1LVznp1PbPDAXhcR+ZagywCtJV1g at>
Content-Type: text/plain; charset=ISO-8859-1

The problem is we're not yet at a point where JavaFX components that can
fully replace their Swing equivalents.  And we may never get there if
vendors believe that there's no market for it (kind of a chicken and egg

> Should JavaFX be able to reuse Swing components?  I don't necessarily
> think it should.
> Existing swing components wont have the CSS styling and would look out of
> place surrounded by a Rich UI.  I feel JavaFX should be looking forward,
> opposed to adding backward compatibility for various Swing libraries.
>  When/If JavaFX is supported on multiple OS's like iOS, Metro, Android,
> would users want to see a Swing component, or would they like to see a
> JavaFX component that looks exactly like it should?
I was speaking about desktop development/applet development primarily where
all of the current Swing development occurs.  The lack of CSS styling for
Swing components doesn't bother me that much and would be tolerable as an
interim solution until the JavaFX components are mature enough to be used
as replacements.

> Though there are swing component libraries that have the functionality
> that is needed in JavaFX, like as you mentioned JFreeCharts, but surely
> thats for a oracle/community to adopt and take forward.  To see that the
> community needs and look to address that with a new feature of JavaFX, or
> new JavaFX library.  Swing libraries grew over time and started tackling
> the functionality that was missing in swing, like a property Chart AP,
> TreeTableView, etc, but we need groups like the JFXtras team to take up
> baton.  That being said, I hope the next release of functionally for the
> JavaFX charts is somewhat comparable to the functionality offered in
> projects like JFreeCharts

Most of the JavaFX libraries I've seen so far provide toy widgets, but not
something that would necessarily be useful for corporate app development.
 Speedometer type dials, and battery gauges aren't really useful when
trying to display financial or scientific data.


End of openjfx-dev Digest, Vol 11, Issue 20

More information about the openjfx-dev mailing list