Some months ago after some serious pondering of the advantages versus the disadvantages, I’ve decided to port my swing application to javafx. It was a perfect match for all my application needs, it was perfect for the animation part since all of it was structured to work as a scene graph. All the scene graph features missing in my swing implementation were already available in javafx, together with a couple other things that I needed.
But there were still some problems though:
- All of this porting would take me a lot of time
- Javafx wasn’t and isn’t still a full featured GUI SDK
- It was risky to bet too much on javafx since it was not yet a proven technology. (I believe this has changed even more with oracles recent statements that it will invest heavily on it).
So because of all of this I decided to go with a less risky, less time consuming solution: only port the animation part to javafx and embed it in my swing app using JXScene. On the future I could than slowly port the rest of the missing things to JavaFX to take full advantage of it, since if the application doesn’t start in javafx you will miss some things. This allowed me to have an usable application in the middle of the porting process.
As time went by JavaFX 1.2 came out and JXScene could no longer be used because of some API changes, so I ported it (also thanks to Andrew Hughes). Here’s a link to the API documentation, it contains some important information you should know when using JXScene: http://jfxtras.org/portal/core/-/wiki/JFXtras/JXScene.
There was still a problem: debugging the javafx side. First I started by doing some printlns but as the program got bigger and bigger debugging with this technique became more and more troublesome. So after some research I found out how to do it properly:
First you have to tell the swing side that you want to run your app and listen to incoming debugging connections. Pass in the following arguments when running with the java command:
-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,address=8888,suspend=n
- transport can also be shared memory on windows if the attached debugger is running on the same machine
- address is basically the port number
- server needs to be y
- suspend if suspend is ‘n’, the application will start immediately and will not wait for a debugger to attach to it. If ‘y’, the application will be suspended until you attach to it.
Then you have to attach the Netbeans debugger to the running app. On netbeans 6.8 do debug -> attach debugger:
This is perfect for me, even more because my swing app is running on a different IDE – IntelliJ, than my javafx app – netbeans.
I was told that doing the opposite was also tricky, that is, debugging a swing component embedded into javafx, so this will also be useful on those cases.
So that’s it for my third blog post. If I was not clear enough, you don’t like my writing or you don’t agree with some things I’ve said please give me some feedback since I’m new to this and still learning.
Thanks for reading, have a nice weekend.