JavaFX is Dead, Long Live JavaFX
So, it seems JavaFX isn’t dead yet after all.
Now that Sun has released a preview SDK of JavaFX over at javafx.com, they must be thinking that it is soon ready for the world. I have previously talked about javafx as being forever unfinished, and this was my opinion of it still.
But today, I set out to try the preview SDK, and it kind off changed my mind.
Starting out, I had to both install a latest and greatest Java6Update10 release candidate and the dreaded Netbeans IDE (which by far was the worst hurdle to overcome). But from there on, things just worked. I followed a couple of tutorials, and built my own Clock JavaFX application stone by stone. And I most say, that even Netbeans did a good job in helping me.
What stunned me a bit, was the feeling of quality and readiness of the JavaFX technology. It just worked.
Here is a bit of what I noted down, when working with it. I might compare a bit with flex/air on the way too.
The Language
- The syntax for defining UI declaratively looks like crap. To me, it is not even the slightest bit intuitive and easy to read. Only positive thing is, that it is easier than gluing up a Swing application in plain Java code. Why on earth have they dreamt up a new syntax, when xml is here for such things? Flex wins here.
- The language for scripting looks much nicer. It seems to be close to actionscript and javascript syntax and it supports stuff like attributes and data binding in the language. Nice!
- Dead cool feature is of course the ability to mix and match real Java code right into the application. JavaFX wins bigtime over Flex/AIR here.
- JavaFX supports multiple inheritance - why on earth that? It gives the compiler extra work, as it compiles into Java bytecode, which does not support this.
Tooling
- I guess this must be Netbeans for now. Not the coolest thing on the planet. Them having dreamt up a completely new syntax, instead of going with xml for declarative UI, will require more work for competing IDEs to catch up.
Components
- At first, JavaFX seems to be centered around the rich media part (Frame, Stage, Animations, Shapes, Transformations, …)
- But of course, Java has the complete Swing apis, with a lot of components to support forms (Buttons, Tables, Checkbox, …). These are components in the Flex world, an integral part of Flex/AIR framework. In JavaFX, they are just there already, because of the complete integration with the rest of the Java platform.
- One can turn the above argument on its head though. Cause flash has had stuff like scenes, stages, animations and transformations for a lot of years. This is new stuff on the Java platform, brought about by JavaFX.
Platform
- Well, fx source compiles to JVM bytecode, of course
- From here on, “everything” is possible
- Target execution platforms includes: Desktop application using JRE, applets in the browser, mobile platforms (cell phones and tvs in the common profile only)
A minor footprint: not all swing components are supported by JavaFx Script (the runtime libraries, not the language) as each component requires a wrapper. The preview does not include a wrapper for JTable or example, same thing will happen for all Swingx, Jide, Flamingo and what not Swing components out there.
August 22nd, 2008 at 22:58Hey Tech Per,
Thanks for giving the Preview SDK an honest once over.
It has its shortcomings for sure - but they’ve (Sun) done a pretty good job so far!
Perhaps you can get more involved in the community to get things really rockin’
Thom
August 23rd, 2008 at 03:15“JavaFX supports multiple inheritance - why on earth that?”
This is because JavaFX does not support interface, therefore JavaFX cannot implement interface, hence multiple inheritance provide the shortfor.
I remember reading something that says how multiple inheritance mechanism in JavaFX be translated and compatible with Java.
You can find some info from this site.
August 23rd, 2008 at 16:59http://java.sun.com/developer/technicalArticles/scripting/javafx/javafx_and_java/#4
I absolutely hate XML and think that using a declarative language was a good idea. XML may have offered some portability, but in the end a syntax designed for building user interfaces will increase readability and overall productivity.
I’m with you on tooling. I’d like to see more in this area.
August 23rd, 2008 at 18:00JavaFX is about quickly and easily making rich applications, aimed at designers who do some coding rather than coders who do some designing. Asking a designer to write XML (with all of it’s nesting, requires to things, and excess characters) would be missing the point. Flex fails here, forcing the use of design tools and causing dread and fear when the declarative code has to be tweaked since any XML syntax error breaks the whole gui.
In fact, when designers will be hand editing config code, easy to read JSON would make more sense than XML… but inline simple syntax makes the most sense of all, which is what JavaFX offers. Note that I have not seen a GUI config file using JSON, which might be a fun exercise to try in JavaFX.
I suspect it won’t be long before someone offers an XML module for JavaFX which supplies the same type of structure as the myriad of GUI helpers used for Swing (or the simpler version used for Flex).
August 23rd, 2008 at 19:07@GeekyCoder:
From the reference you linked to, it says:
so, it seems fx classes can implement interfaces.
August 23rd, 2008 at 19:28@Rob
Thanks for the comment. Don’t get me wrong. I am all for a declarative language for the ui too, but I hate the syntax. To the best of my knowledge, you also define the ui declaratively in flex, just in another syntax, xml.
I know xml has taken a lot of beating lately, especially in the Java world, after annotations came to, that could take some of the configuration elsewhere, which was always done in xml in the past. But for defining a ui hierarchy of components, I have found the xml syntax in flex to be really nice to work with. There *are* areas where xml can be used, and I think this is one of them. Of course, that is just my opinion.
August 23rd, 2008 at 19:32@Michael Wexler
Interesting thoughts you have there. I am not sure I follow you on all of it, though
Are you serious, that you think designers in large, will be editing JavaFX code themselves with pleasure? And that this should be any easier than xml? There is lots of syntax in fx too, that must be damned right, for anything to work. There’s nesting too in fx code. Any syntax error in fx code will also break the whole ui.
I haven’t seen one framework yet, which can let a designer do the design in a language and format, that can be integrated with the businesslogic without change. There has been plenty of trials on this, and one that came close was the template system in Tapestry. But it still failed, when ui components was extracted from the the templates, because template preview became broken then.
JavaFX (and Flex) tries too, but they ain’t getting any closer, in my opinion. In theory, a designer should be able to define the ui, and then it should only be a matter of data binding the ui to the code. But this fails for anything larger than a teaspoon.
August 23rd, 2008 at 19:44@polesen
I agree that no one has done it well… And I don’t expect a visual designer to fire up XMLSpy to edit a config doc. But I do expect to see them draw a design and want to modify behaviors that are difficult to express graphically. I think we both agree that, although neither are inviting, XML is probably more scary than a simple JavaFX syntax. For a programmer, of course, it’s fantastic, as it allow programmatic management of UI config files with minimal effort. And many programmers are talented with hand editing XML files, as they are lingua franca of everything from distributed build environments to editor config files and everything in between. But I continue to believe, based on the UI designers I have met, that the XML approach is additional complexity from their POV.
After trying languages like processing.org, it becomes clear that there are simpler ways to design visual experiences without resorting to the complexities of a modern MVC world. Certainly, you wouldn’t build OpenOffice in Processing (nor in JavaFX), but it’s just a way for some designers to start experimenting with programmatic expression. I doubt it would be as popular if it forced the designer to code in XML.
I agree: JavaFX and Flex are trying. And yes, the separation between business logic and front end design is wonky in all of these languages (and web frameworks and the rest of our modern stack). And maybe we will never hit a world where a really complex app has complete separation of M, V, and C.
But I do see a world where designers can create some pretty good stuff with minimal coding. And I do see a world where that minimal code creates, by default hooks in for a back end to help with the business complexities.
It’s not right now, but languages like JavaFX and Processing are giving hope that we can get there. I don’t think requiring XML is necessarily the right answer for a designer. But if you are correct, then it may be the best way we can get there sooner.
August 23rd, 2008 at 21:14[...] JavaFX is Dead, Long Live JavaFX (em inglês), por Per Olesen, 2008-08-22, impressões sobre o Java FX Preview SDK, disponível para download gratuito. [...]
August 25th, 2008 at 07:20