Peter Pilgrim is professional software developer, designer and architect. Since 1998 he has worked in the financial services industry, investment banking mainly, developing IT for clients. He is a well known specialist in Java Enterprise Edition (Java EE) technology, focused on the server-side and the implementation of electronic commerce. Peter has built professional Java EE apps for top-tier investment banks such as Lloyds Banking Group, UBS, Credit Suisse, Royal Bank of Scotland and Deutsche Bank. Peter is the 91st Oracle Java Champion. Peter is a DZone MVB and is not an employee of DZone and has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Why Should I Invest In Learning JavaFX?

07.28.2009
| 7569 views |
  • submit to reddit

This following blog presentation is also available in audio as an AudioBoo: "Why Should I Invest in Learning JavaFX?".

What functions does your customer or business analyst want to see in the final application?

What are your project's aims?

Do you want an application with richer graphics, such as advanced 2D and media support?

If so, then a rich internet application framework probably suits you better. Any of JavaFX, SilverLight, Flex will do, then you must drill down into the user story and capabilities of each.

Does your user story restrict your project to HTML standards, in particular HTML 5?

If so, then choose an AJAX framework, Dojo, JQuery, Ext JS and an appropriate Java Web Application framework. From there you can drill down in the technology, which best maps to your user story.

JavaFX, even at its 1.2 release, probably at this point is better way of building a Java Applet, because I do think it is the future of client side Java UI. It is much easier to build an application front-end quicker in JavaFX, because of it declarative nature code, and because the language support binding and triggers.

I bet there are lots of you who are very experienced with Java Servlets and some of the earlier application framework build around the former's API. I believe that JavaFX feels like Struts 1.0 (circa 2001) at the moment to me in my opinion, in that if you get involved now you are still ahead of the curve, rather than six months down the line when, probably, everyone else will come aboard. In other words, I do believe that FX will get substantially better, because the community writing code and components as well as Sun developers. Also the platform is becoming more stable as time progress, the standard APIs and the concepts settle down.

The biggest differences between JavaFX and Struts touchy-feeling thing are

  1. The huge codebase in JavaFX in comparison to Struts 1.x.
  2. The life expectancy and the goals for JavaFX
  3. The FX runtime is not open source, but the compiler is.

Let us deal with these in turn.

The Huge Codebase in JavaFX in Comparison to Struts 1.x

 The original inspiration for FX was Christopher Oliver, F3 project way back in 2006, 2007, where we invented an interpreter called Form-Follows-Function. He was a Swing Developer, who wanted a faster way to build GUIs. So he thought about creating a little scripting language (obviously) to speed-up Java user interface development.

 Here is a decent article http://research.sun.com/minds/2008-1202/

 Chris Oliver blog http://blogs.sun.com/chrisoliver/

 So this simple interpreter, a proof-of-concept, with a much smaller codebase, eventually became the JavaFX runtime, the statically typed language compiler and scene graph and much more. The result is a explosion of the size of the entire code base, and if you have read Fred Brooke's book, about throwing programmers into a project. Well you already know the answer. The software takes as long as does to get right and no sooner than that.

In comparison Struts 1.x had lesser lofty goals. Tomcat already existed at the time and there was a Servlet standard API to use. You might disagree about the overall analogy and be that as it may.

The Life Expectancy and the Goals for JavaFX

If you are going to produce a new JVM platform extension, then that takes time to envision and produce. You have to build a little bit, then test it, then build it again and then test again. Every project in the planet suffers from this reality versus implementation goals from Google Wave to JavaFX to the Linux Kernel. It just happens that Rome was not build in a single day.

I believe the lofty goals in JavaFX were / are / are going to be:

  • Complete Chris Oliver's original vision, make it easier to write GUI applications in JavaFX in comparison with Java Swing.
  • Update the technology of the Java User Interfaces on the desktop. A scene graph is ultimately much better than the old fashion way of immediate-mode

    GraphicContext.paintEllipse( x, y, width, height );

In comparison, JavaFX needs only the component and a container to be declared.

    Scene{
content: [
Ellipse {
centerX: 100 centerY: 100
radiusX: 50 radiusY: 25

fill: Color.YELLOW stroke: Color.BLUE strokeWidth: 3
}
]
}


  • Create a better Java based scenegraph allows nodes to be transformed: translated, scaled, rotation with high performance.
  • Fix the Java applet and web start client runtime

Changing from immediate mode to scene graph node mode, at inspection, implies a performance penalty, at least from software engineering architecture, because it is one more layer of indirection between the graphics primitives being the sent to the GPU. Ultimately, Sun, need to solve the performance of rendering 10000 of nodes (in future applications) to the desktop. Pick up any computer graphics book (written by like Foley, McGregor and Watts) and you will see algorithms like Sutherland Clipping and Z-Order sorting. One, then, needs to read up and hardware accelerations books and more hard-core books to figure how to program Direct X and Open GL GPU instructions. This is the runtime part of JavaFX platform that also benefits normal Java developer as well, because improving 2D performance ulitmately benefits both.

  • Push the compiler so that optimises the JVM considerably

Then there is the FX language compiler. The current JavaFX language reference is quite different from Chris Oliver original F3 interpreter. You will find that Brian Goetz, author of Java Concurrency and Practice, is working alongside Per Bothner, a language compiler wizard to get the compiler doing nice things. Compiler is now producing decent enough byte code such Hotspot in the Sun JRE can do the rest.

The FX Runtime is Not Open Source, But At Least The Compiler Is

Up until May 2008 the runtime was open source. I think the scene graph project was also open source, at one point. Around 15 months ago (May 2008), an executive decision was taken to bring the runtime back into close source. The development community outside Sun were excluded from seeing the changes.

On the one hand this is fair enough. It means that Sun can design the runtime and scene graph quicker without interference. This should not be upsetting to anyone at all. After all it is their business and companies are allowed to develop close source software. Google, did it with Androidand is doing it with Wave, until they decide it is ready for a release. The move was not illegal. It was some what surprising that the early access changes disappeared entirely.

On the other hand the decision to not release often or give clear guidance what is happening with certain design decisions has, in my opinion, hurt the JavaFX project and community a little. For example, I wanted to get a component design guide, and I asked for this, yet no one from Sun could provide one. So many developers stumbled trying to create their own components. We invested in a lot of time, experimenting with the released or open parts of the JavaFX platforms. Obviously, components are those GUI elements that are needed now, if Sun Microsystems want to compete with Flex and SilverLight in the markets. It did not make sense to me to provide only fleeting support for those early JavaFX adopters.

Having and said all of this, I realise that writing a runtime, compiler and scene graph, and get all of this working on a desktop, mobile (and let alone TV platforms) profiles is flipping hard. I believe Sun need more openness in overall design and they need to engage the community a lot more.

 

Examples of User Community Work

If you want to see more user-contributed components then have a look at my Nelson Framework examples (http://www.jroller.com/peter_pilgrim/entry/the_nelson_framework ). (These are FX 1.1 examplese and I am current re-engineering the Table UI component). My open source project is on Kenai (http://kenai.com/projects/nelson )

 Also look at Stephen Chin's JFXtras project (). And look at Stephen Chin's WidgetFX framework. Then there is Josh Marinacci's JavaFX samples .

Then there are dozen's of learning articles and blogs at there too - http://learnjavafx.typepad.com/weblog/

And the official JavaFX tutorial which is is *strongly* recommended for complete FX beginners.

In conclusion, the future can only be brighters, because there are enough passionate JavaFX developer who believe in the platform and the mantra "reinvigoration of the desktop". We now need better communication, more release often and a bettter guidance.

From http://www.jroller.com/peter_pilgrim

Published at DZone with permission of Peter Pilgrim, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Manjuka Soysa replied on Tue, 2009/07/28 - 11:34pm

I've been mulling this over.. is JavaFX really Java? It's not the same language, and it doesn't have to be based on JavaSE or JavaME. Is it any more Java than say.. Javascript?? It just happens that the currently available implementation of JavaFX is built on the Java SE Runtime.

I guess the powers that be at Sun realised that JavaSE is too bloated and JavaME is too primitive to be a popular application platform on next-generation web-friendly devices (smart phones, net books, set-top boxes, etc).  JavaSE was designed as a general-purpose development platform on top of general-purpose operating systems, and had to 'wrap' all the functionality available on those OSes. JavaME was designed for older-generation devices with limited computing power.

The expectation in the community (and may be at Sun) was that as devices get more powerful, they will support JavaSE. However it seems that the bloat of the JavaSE has exceeded the growth of computing power :-) Probably a bigger reason is that deployment of applications (other than Applets) always had unresolved issues.

JavaFX addresses all these issues and more. But it is not Java. If light-weight OSes (ala Chrome) become dominant on the desktop some time in the future, Java will die a slow death on the client side, while JavaFX will be able thrive. Well worth investing some time on it!

Andrew replied on Wed, 2009/07/29 - 12:36am

I think you contradict yourself by saying that "If light-weight OSes (ala Chrome) become dominant on the desktop some time in the future, Java will die a slow death on the client side, while JavaFX will be able thrive." Light-weight OSes (ala Chrome) are pushing their own agendas and their own client app environments (like Javascript and HTML5). They dont care about JavaFX.

Manjuka Soysa replied on Wed, 2009/07/29 - 12:47am in response to: Andrew

Well, I did say 'will be able to'.. no guarantees. I think JavaFX can co-exist with Javascript, HTML5 and Flash on Chrome OS. But I do agree that its success will largely depend on how inclined Google is to include it in the base distribution. Not expecting JavaFX on iPhone or Palm WebOS soon :-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.