Migrating commercial applications from Swing to JFX

[Daniel Zwolenski]

Another consideration (which I mention in that interview you referenced) is
deployment. How broad is your audience, are you going out to every random
user everywhere or do you have control over the machines that your system
will run on (e.g. an internal corporate app)?

Be aware that in my experience Applets and JNLP are not reliable (and are
on the way out anyway as browsers will start to lock them out before long -
this applies to both Swing and JFX). The only strong option is native
installers and these are still very much under-cooked (I had trouble for
example getting a native DLL to load when a native installer was deployed,
whereas it worked fine through other deployment options). There's no
auto-updating, the app distro sizes are large, the tools are cludgy (things
are hard to customise; you have to build each release on the target OS,
etc; often you have to download and install third-party build tools). All
of this is probably targeted to get improved, but it's going to take time
(I'd hazard a guess you'll be dealing with these issues for many months
probably some of them for years).

I would agree that if you are using JFX you will find many great aspects
but be prepared to feel like you are using something that is still a
work-in-progress and conversely not rapidly solidifying. e.g. we are a year
(or is it two?) since the official release of JFX2 and the ability to
maximise your main window just got added yesterday (and won't get released
for a bit yet). There's some real fundamentals like this that you will find
yourself having to work around and the improvements happen slowly
(months/years, not weeks) as everything is tied into the JDK release cycle
with all the caveats that go with it.

In terms of ditching Swing though, that's a no brainer in my opinion. It's
more just a question of what you go to (native, jfx, etc, you can do a heck
of a lot with browser-specific web apps too these days, even native stuff:
https://developers.google.com/native-client/). JFX is a very good option
(depending on the factors discussed here) but it certainly won't be a
magical, experience where everything just works.

And if you're interested in mobile, the "official" stance on this is still
that it will not be supported. There is a lot of secret whispers and hints.
But unfortunately the same hints and whispers were there right up to the
JavaOne announcement that they were not going to support mobile. Hope for
the best but plan for the worst.





On Thu, Jan 24, 2013 at 9:33 AM, Scott Palmer <swpalmer at gmail.com> wrote:

> What is the time frame for your conversion?
> As a complete replacement for Swing, JavaFX 2.x is immature.  There are
> rough edges.  I started the conversion of a Swing app to JavaFX last year
> and hit several issues.  Though many of them are minor, they are enough to
> get in the way of releasing a commercial quality application.  We did find
> JavaFX too compelling for one aspect of our UI though, so our first release
> will be Swing + JavaFX (via JFXPanel). JavaFX 8.0 looks to have addressed
> some of the issues I ran into, and I am evaluating it so that I can get any
> remaining issues filed ASAP.
>
> You mentioned OpenGL.  One thing lacking in JavaFX is any way to embed
> native drawing routines or windows into a JavaFX UI. Swing/AWT had the JAWT
> JNI stuff that let us integrate some native drawing or add OpenGL views
> etc.  This has been an issue for us, as we are also dealing with video
> media and would like to have control over our "preview" window.  The JavaFX
> media APIs are too superficial. They don't allow for enough customization
> and control, and even if they did they still may not be appropriate for our
> use case.  There is the Canvas concept where you can just set the pixels
> the way you wish, but it's current design is flawed and we were unable to
> use it as it destabilized the application.  (We are also concerned about
> performance with that mechanism - it isn't the same as having a window
> handle that we can just paint on with native code.)
>
> I am not worried about JavaFX "being abandoned".  I think we have seen
> enough from Oracle now to see that they are committed to it and putting in
> the effort.  JavaFX development is much more transparent than Swing.  The
> JIRA issue tracker is generally more accessible and we can see activity
> whereas with Swing there was little feedback after issues were filed.  The
> open sourcing of JavaFX is also something that will help strengthen the
> platform and provide some safeguards against it disappearing.
>
> In general the JavaFX APIs are better to work with than the Swing
> counterparts.  Simple things like using the collections APIs and adding the
> concepts of bindings really help productivity.  JavaFX Scene Builder is
> great.
>
> So I would conclude that simpler applications can be made to work well
> with JavaFX 2.2 today, but porting more robust desktop applications that
> use much more of what Swing provided will need JavaFX 8.0 at least.  If you
> relied on JAWT or other tech to get OpenGL integrated into your UI there is
> currently no replacement that I am aware of.  The expectation is to do
> everything through JavaFX APIs, and they do not cover everything that could
> be done with JAWT.  Even if you went with JNI for a fully native
> implementation for an OpenGL window for example, there would be no way to
> use a JavaFX Stage as its parent without hacks.
>
> Integration of JavaFX UI with native code has not been considered as far
> as I can tell. (I would love to be corrected on that).  You can even see
> this in the JFXPanel Swing integration layer, where JavaFX dialog windows
> can't get a proper parent window from the Swing layer.
>
> Despite the current shortcomings though, we have decided to push forward
> and complete the port to JavaFX of our main application.  If we have to do
> some native hackery to dig out window references so we can provide proper
> parent windows to UIs we do natively (e.g. video preview) then we will.  It
> is not ideal, but the JavaFX UIs look much better and coding to the JavaFX
> APIs is more productive for most things.
>
> Regards,
>
> Scott
>
>
> On 2013-01-23, at 4:39 AM, Robert Krüger <krueger at lesspain.de> wrote:
>
> > Hi,
> >
> > this may be a bit off-topic, so sorry for that, if it is too much so.
> >
> > We are currently in the process of deciding where to head with the
> > development of our product, which is a Swing application with some
> > native code for special things like video decoding, Open GL, access to
> > special platform APIs, currently targeted at the Mac platform but
> > potentially to be ported to Windows as well at some point in the
> > future.
> >
> > With Swing being no long-term option, we are in the process of
> > deciding whether we take one of two approaches:
> > 1) Make the UI layer as thin as possible and put native UIs on the
> > Java core (we have lots of non-UI libraries that we have invested a
> > lot of work into)
> > 2) Switch to JFX for the UI
> >
> >> From an academic point of view the choice is obviously option 2 but in
> > real life things like quality/maturity and future relevance/support of
> > the UI technology can make this decision non-trivial.
> >
> > Properties of the two solutions AFAICS:
> >
> > 1)
> > - Best native user experience
> > - More native code, i.e. potentially larger team required to maintain
> > app on two platforms and significant work will go into boilerplate
> > stuff to bridge between the two worlds despite technologies like Swig,
> > Bridj etc.
> >
> > 2)
> > - Development probably most efficient and all Java, which makes
> > tooling easier and you probably need to write a lot less
> > platform-specific code (in our case we always will to some extent)
> > - User experience will probably be at least a little less top-notch
> > compared to native stuff (at least judging by what I saw when playing
> > around with the ensemble app I got through the Mac app store, it is
> > still a bit beta)
> > - Risk of JFX not being a success and being abandoned by Oracle in 2
> > years (especially if they do not decide to release the mobile JFX
> > impls they are said to have, IMHO that would be the absolute game
> > changer for platform adoption)
> >
> >> From the development point of view I would like 2) to be the way to go
> > but we are still rather unsure. 1) would definitely be safer (though
> > more painful in a number of ways).
> >
> > I read the interview at
> > http://fxexperience.com/2012/08/interview-with-daniel-zwolenski/,
> > which is encouraging but that is one opinion and I would like to get
> > more opinions of people in a similar position.
> > I think answers to that will probably be of interest to quite a number
> > of small ISVs.
> >
> > Apart from opinions, examples of real-world products, developed using
> > JFX would help. Ensemble is more or less like Swingset and these
> > things do not tend to really show if something is ready for prime time
> > and I guess it will take a while until Oracle ports Netbeans to JavaFX
> > (that would be a large application :-)).
> >
> > If this is the wrong place to post something like this, please advise
> > were else it would be appropriate.
> >
> > Thanks in advance,
> >
> > Robert
>
>