Updated (16 April)

To better plan my projects I’ve always been nosing around trying to figure out what to expect on future JavaFX releases.

After someone on a thread asked me to tell him what I knew about what is to come, I figured that since the list is a bit extensive and other people might be interested in knowing I’d do a post about it on my blog.

So here is what I know so far:

• New graphics stack called Prism, no longer dependent on awt/swing. Expect better performance.

(Update: You’re probably able to choose whether or not you want to use Prism )

• All bindings will be lazy (not sure how will that cope up with the rest)

(Update:The runtime will figure out what type of bind to use and always try to choose lazy over normal bind to get better performance. The scene graph has been changed to better accommodate lazy binding. On replace triggers will use normal binding by default.)

3D:

• 3D Space with 3d transforms putting 2d objects on a 3d space.
• Perspective and Parallel camera – probably the same feature that exists in Java3D
• Bounds now is on 3D

A little bit disappointed that there will be no 3d shapes, I needed that on my app. But than again there aren’t probably many people needing this.

(Updade: Just reminded that 3d shapes are done with transformed 2d shapes like triangles or squares, duuuuhhhhh! So you should probably be able to create 3D shapes yourself using the existing 2d shapes.)

Controls:

• Multi-line TextBox (TextBox is a text input field)
• Better skinning API. Added Regions
• Caspian Skin
• Password Box control
• Separator control
• ChoiceBox control. (not sure what this is, if someone knows please post a comment) Its a non-editable ComboBox
• Spacer Control (for layout purposes)
• Custom cell support on Lists
• Menus
• ToolBar
• Tree
• CSS support for charts

The biggest miss here is Table. Of course you can always rely on Swing Table

Graphics:

• Support for custom cursors
• Filling shapes with a texture

That’s all I know, also expect bug fixes and performance tuning here and there. I’m guessing It won’t take long for 1.3 to be released.

I think this release will give the so much needed boost to JavaFX: except for the table almost all standard controls, better performance, 3d capabilities and some other nice goodies.

Edit: Don’t forget that this is only what I suppose will be available on 1.3. These are not facts and somethings are probably wrong or not 100% right

Image by noor.hilmi.

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.