Migrating commercial applications from Swing to JFX

Richard Bair richard.bair at oracle.com
Wed Jan 23 09:06:22 PST 2013

Hi Robert,

Those are great questions and I'll let other folks on the list give you their experiences (good or bad). The primary thing I'd recommend is that you take a couple weeks and do a quick prototype and see how it works for you. What is the most likely thing that will be a problem? Is there a unique performance related issue? What about the OpenGL code you've written, how will that work with FX (use the new 3D APIs we're adding in 8, or does the existing OpenGL code need to coexist)? How important is native look to your users?


On Jan 23, 2013, at 1: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

More information about the openjfx-dev mailing list