12/30/2008

JavaFX - some first deeper impressions

I'm still very thrilled about JavaFX -- don't get me wrong, but I'm and more and more disappointed too.

This begins with that I feel like an early adopter of an alpha-stage technology working with JavaFX 1.0. The more I look into that technology the more I'm wondering: is JavaFX supposed to encapsule Swing or not? I thought it will be an abstraction? Under the hood you use well-known components like JButton, but pretty nicely hidden and wrapped through FXNodes, SGNodes, SGParents and many other components. Other controls are native JavaFX components like TextBox/text. Some kind of missing consistency ...

The whole interoperability JavaFX/Swing is really, really bad. Working with the ScriptEngine isn't the optimum right? Being dependent on getResourceAsStream is so error-prone. Actually I'm wondering who was the target audience for JavaFX 1.0. I guess not the Java / Swing developers ... ?!?

The next is the tooling .. ok, a lack of tooling is not a big surprise as long as no stable spec is available. I tried JavaFX with NB 6.5 and it is pretty ok, but I hack my scripts inside the NB editor just to valid that they are correct and then copying them into my IntelliJ IDEA or Eclipse workspace. Why? I'm not sure ... but it starts with that NB distinguishs between Java and JavaFX artifacts and projects everywhere. What a pain.

The whole JavaFX stuff gets better .. starting from zero at JavaOne 2007. But I have the impression for JavaFX the whole product is still driven by (suboptimal) marketing, not by software engineering. And all that with a lack of communication ..

7 comments:

Jim Weaver said...

Michael,

My 2 cents, keeping in mind that I don't wor, or speak, for Sun:

Java Swing and Java 2D are really two different worlds that pre-JavaFX 1.0 versions tried to handle simultaneously. To "cross" from one world to the other, adapters were needed (Canvas to draw 2D on components, and View to put a Swing component in a 2D scene). JavaFX SDK 1.0 takes a node-centric approach, where all UI elements are a Node subclass, and can be put on Scene. I really like this approach because it is conducive to creating graphically-rich, iPhone-esque/Web 2.0++ applications that users will increasingly expect.

Regarding the lack of Swing components within JavaFX, you can use use any JComponent by wrapping it with the SwingComponent#wrap function in the javafx.ext.swing package. As you implied, there are some under-populated packages, due to Sun's commitment to release a 1.0 version in Fall 2008. For example:

The direction (as I understand it), is to build out the javafx.scene.control package with CSS-styled, skinnable, controls. The one control that exists in SDK 1.0 is javafx.scene.control.TextBox, which you can experiment with. See the following blog post for an example of using CSS to style a TextBox:

http://javafxpert.com/weblog/2008/12/part-deux-of-bulding-a-calculator-with-the-shiny-new-javafx-sdk-10.html

Also, the javafx.scene.layout package will contain more layout classes than the ones that exist today (HBox and VBox). These layout classes will be nodes, and will contain nodes. On that subject, there is an open source project led by Stephen Chin named JFXtras whose purpose is to help fill in the gaps of the JavaFX 1.0 release. Among other capabilities, it provides a node-centric Grid layout. Check out the following post to see more information on the JFXtras project.

http://javafxpert.com/weblog/2008/12/jfxtras-01-release-utilities-and-addons-for-the-javafx-language.html

By the way, I read second-hand that the author of the MigLayout is porting it to JavaFX.

Oh, and I definitely agree with you that there are opportunities for JavaFX tool development ;-)

Anonymous said...

You forgot the biggest disadvantage of JavaFX. It is a pur Sun-technology without any backup from other companies representing the JCP. There will be no JSR for JavaFX. The whole thing is as proprietary as Microsoft SilverLight and Adobe Flex - despite having a FOSS-licence (probably the "usual" combination of GPL V2 and commercial licence)

Anonymous said...

Not to mention there are still some significant bugs. I've found a couple (and reported them). But here's the thing. A 1.0 version is still quite early-stage. Remember, there was a Java 1.0 version at one time which was quite limited and had a number of problems. Java 1.1 was somewhat incompatible with 1.0 when it came out as I recall.

Anonymous said...

Significant bugs indeed! (reported a number as well) I'm at the point where I wonder how many unittests were written; JFX 1.0.1 can't do a move-and-opaque correctly.

If that many resources have gone in to it, even SwingX was abandoned, that kinda amazes me. IMHO JFX is not 1.0 material, according to (let's say) open source standards.

Michael Hüttermann said...

@Jim, Swing and Java2D are traditional, existing client GUI technologies. I'm wondering about the bridge between JavaFX and the existing, old-school technologies. Is JFX an abstraction to those technologies? How can I access those components? How can I access a JFX-app from outside an old-school Java application? The current approaches are really suboptimal. I think more documentation and communication or actually a specification could result in more understanding on all sides.

@Anonymous, yes a spec or even better a JSR would be best! I would expect one, where is it ?

@Lobochief, absolutely right! Actually at this stage the difference between a bug and a missing, incomplete feature is fluent. ;)

@Tom, reading Jim's answer in that thread I'm wondering more and more about the real goal of JavaFX. With understanding the original requirement it is hard to value the state (bugs, features). Tom, you are absolutely right, I would like to know the number of unit tests too. :) This comes to the question why creating a total new language and syntax?! Written in a well-known language (Groovy?), also unit testing the artifacts would have been a lot easier. But everything had to be invented new from scratch! ;-)

Michael Hüttermann said...

A small correction, in the last post I of course mean: "Without understanding the original requirement it is hard to value the state (bugs, features)." Sorry. :)

Sildenafil Citrate said...

I read your impressions on JavaFX and I have some similar thoughts after I tried it. By the way, don't worry about the small mistake you made in your previous, we totally understand!