Migration from Windows C based GUI to JavaFX

Hello,
We currently have a Visual C++ ( sort of )/GTK based windows GUI. Here is the current structure ( right or wrong ). Please note that the basis of this was an entirely text based screen system that morphed into the below structure probably 15 years ago.
1. Design screen and data handling application in C, running on *nix based systems
2. Low level code on Linux side communicates a formatted message via socket to frontend GUI that runs on Windows. This message is a "|" separated string, currently, that has the "function" we want to call in the GUI frontend, with the "functions" parameters.
3. GUI frontend that runs on Windows only, and is written using Visual C++, depending on various libraries, like GTK. It reads a message from a socket, parses the message, and then adds the requested information or screen element to the GUI screen we are building. This includes filling forms with data, filling spreadsheets with data, building dropdowns, etc.

Sadly, I cannot argue changing steps 1 or 2 at this time, but I have convinced my boss to consider changing things at step 3. So, we were sort of thinking of at least moving the Windows GUI portion to some other technology that would, eventually, give us more flexibility. So the new structure would be something like this:

1. Design screen and data handling application in C, running on *nix based systems
2. Low level code on Linux side communicates a formatted message via socket to frontend GUI that runs on Windows.
3. GUI frontend that runs on different platforms ( especially Windows ), and is written using some more modern tool that gives us flexibility. It reads a message from a socket, parses the message, and then adds the requested information or screen element to the GUI screen we are building. This includes filling forms with data, filling spreadsheets with data, building dropdowns, etc.

So, my question is this: Do you think JavaFX would be a good option for something like what I am describing above? If JavaFX is not a good idea, do you have any other ideas? Any pointers would be much appreciated. Even a recommended book or website would be helpful. If I am asking the wrong types of questions, then please tell me. Even that would help me come up with a better plan of attack. Thanks.


Tony

Your options in terms of front end technology are html, native app, Java (swing or javafx or a swing/javafx hybrid), flex/air/silverlight.
It is hard to advise on good platform for your app in a forum, especially without more info.
JavaFX is a good choice for many applications - may be for yours - hard to tell.

JavaFX is still a new platform, very much under development, the basics are there, but there are few higher level tools and frameworks for building larger applications (e.g. no validation or form fill framework, no spreadsheet component, no native pdf viewer etc). Many of these deficits can be overcome via launching native apps such as pdf viewers, using JavaFX's embedded WebView browser or embedding JavaFX in an existing Swing framework like NetBeans RCP. Run through some of the JavaFX sample applications and tutorials and try out the SceneBuilder before you decide on JavaFX - that way you will have a better idea of the capabilities and limitations of the platform.

What kind of forms does your application cater for? pdf?
Are the forms display only or read/write?
What kind of spreadsheets does your application cater for? excel?
How sophisticated are the spreadsheets? Do they use formulas/totals/etc?
Are the spreadsheets display only or read/write?
What are the other potential target platforms than windows?
Is distribution and installation of an application an issue?
You mention moving to another technology to gain more flexibility - what kind of flexibility do you desire?

> recommended book or website would be helpful.

All of the below are recommended resources:

JavaFX Home Page
http://www.oracle.com/technetwork/java/javafx/overview/index.html

JavaFX Ensemble Demo App
http://www.oracle.com/technetwork/java/javafx/samples/index.html

JavaFX Doc Page
http://docs.oracle.com/javafx/

JavaFX SceneBuilder Preview
http://www.oracle.com/technetwork/java/javafx/downloads/devpreview-1429449.html

15 part series on building enterprise apps in JavaFX
http://www.zenjava.com/series/building-jee-applications-in-javafx-2-0/

Pro JavaFX2 book
http://www.amazon.com/Pro-JavaFX-Definitive-Clients-Technology/dp/1430268727

JavaFX by Example book
http://www.amazon.com/JavaFX-2-0-Introduction-Carl-Dea/dp/1430242574

JavaFX forums for further questions
https://forums.oracle.com/forums/category.jspa?categoryID=298

FXExperience blog
http://fxexperience.com/2012/01/2012-javafx-resolutions/
http://fxexperience.com/2012/06/javafx-the-10000-foot-view/

Thanks so much for your reply. You really helped me clarify my thinking.

Let me answer some of your questions, then I will get to looking more closely at those resources you pointed out. They look quite helpful:

What kind of forms does your application cater for? pdf?
Are the forms display only or read/write?
What kind of spreadsheets does your application cater for? excel?
How sophisticated are the spreadsheets? Do they use formulas/totals/etc?
Are the spreadsheets display only or read/write?
What are the other potential target platforms than windows?
Is distribution and installation of an application an issue?
You mention moving to another technology to gain more flexibility - what kind of flexibility do you desire?

First of all, this is all GUI. Our current application is a standalone GUI, in fact. I don't know if that is clear in my original message.

1. Forms GUI and display data from our database ( or default data )
2. Some forms are display only, some are read/write, and some or editable only in certain cases ( based on configuration or other fields in the form ).
3. Spreadsheets look like excel. In fact, we have a special feature that lets the user right click on the SS to export it so that it can be easily pasted into excel. But it is not Excel, it just looks like Excel.
4. Spreadsheets are very simple, with no formulas, etc. If there are totals, they are put into fields that are external to the spreadsheet.
5. As with the forms, some spreadsheets have editable forms, some do not, and some only have editable columns in certain cases. Actually, in our current code, it is implemented as a movable form ( sort of ).
6. the platform we are committed to supporting is Windows. The main reason I was even considering this was because it has been a pain migrating it to Windows 7 from Windows XP. So I thought another technology might be a little easier, and would offer us the selling point of saying that our GUI can run on other OS ( like Mac or Linux, or maybe even on Mobile Devices ). These other platforms are just a pipe dream. The only required one is Windows.
7. Yes, distribution and installation are potential issues. Right now we have an update application that is used to download the changes.
8. When I say "more flexibility", I largely mean more modern and more supported technologies. Here are the issues and pipe dreams I am considering:
a. Cross platform support, as stated above. Right now it is impossible to run our GUI on anything but Windows. I would at least like to be able to more easily port to new platforms, even if it does not work "out of the box".
b. More easily fix some of these Windows 7 issues I am having because I can use a new technology
Yes, a lot of this is more perception then anything else.

Thanks again for your advice and perspective. You were a huge help. Even answering your questions clarified my thinking. Thanks.

Based on your reply JavaFX seems like it could be a reasonable technology choice for your GUI front end.
a. You could use an editable TableView for your spreadsheet like functions.
b. And use other UI controls for the form filling.
c. JavaFX will provide flexibility for deployment on other platforms (e.g. Macintosh and Linux clients) - most likely the desktop platforms will just work out of the box.
d. No commitment has been made from the JavaFX team regarding Metro deployments. I'd say a Windows 8 desktop client on Intel support is a certainty pretty much as soon as Windows 8 is officially released. Support for ARM based platforms and Windows RT is not as certain at this stage.
e. Touch support is being added to JavaFX and it is likely that deployment on tablet and phone based systems will be available in the future. But just keep that as a pipe dream for now unless you really need it - deployment of JavaFX to such platforms is not a reality today and it is likely that your app would need to be specifically targeted to such a platform to get a good user experience.
f. Networking and connecting to a server supplying your encoded messages with a | seperator should be simple using basic Java network features.
g. JavaFX has a number of distribution and deployment technologies (standalone apps, web connected distribution and updates via webstart, apps embedded in browsers). Newer versions of JavaFX will feature tools to package the app+Java+JavaFX as an installable package for each target platform (e.g. msi for windows, dmg for mac, rpm for linux) - might be the way to go for your app - the update strategy for such an app is still not clear at the moment, though it is something the JavaFX team is currently working on.
h. Converting your client UI to JavaFX is likely a significant investment - so try to make sure that is worthwhile versus potential other tasks which could be undertaken.
i. Sometimes adopting new tech for an existing app can be that you swap the devil you know for the devil you don't. Personally I would prefer to develop UIs in JavaFX than Windows C++ native. However, Windows C++ native has a long and successful development track record and you would need to reskill to get up to speed on JavaFX - don't underestimate the effort this will take.

Thanks. This was a huge help.