Migrating commercial applications from Swing to JFX

[Scott Palmer]

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