Migrating commercial applications from Swing to JFX

[Pedro Duque Vieira]

Hi Robert,

You can do a mixed thing and start porting some of your swing app to javafx
and leave other parts in swing. It will be less risky and you can get a
feel for the benefits/disadvantages of JavaFX. Than gradually, you'll start
to have more and more things written in javafx.

I did that with an app I do called Modellus. You can check it out here
modellus.co, it's free. It was all written with Swing and now the animation
window (the biggest component of the app) is all Javafx and the rest is
Swing.
I'm happy with the change, but it was a lot of work, contrary to what you
can read on the web it is not that easy to port but it is not difficult
either. I also made a lot of changes to the original code, so it was not a
straight migration which ended up taking more time.

Hope this helps, cheers,

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


-- 
Pedro Duque Vieira