Jim has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

JFX and the Way Forward After JavaOne 2008

05.12.2008
| 6455 views |
  • submit to reddit

For me, JavaOne 2008 was enlightening, exhilarating and exhausting.  It was great meeting colleagues that I had only known via email and JavaFX mailing lists.  I'd like to especially thank all who suffered through my JavaFX University and technical sessions :-)

There were several JavaFX-related announcements and demos at JavaOne, not the least of which is the preview release of the JavaFX SDK due in June 2008.  As the interpreted version of JavaFX was the prototype for the compiled version, the javafx.ui classes are the prototype for the javafx.gui classes that were shown at JavaOne and will be released in the SDK.  These javafx.gui libraries will have a streamlined, faster performing API, as well as support for multimedia.  In June, JavaFX will have turned a significant corner, out of the prototype stage and becoming more mature. 

I've started a category on my blog named "JFX" that will contain posts that I'll write about JavaFX in its grown-up state.  This will help you be prepared for the June 2008 SDK preview release.  In the meantime, the version of JavaFX that I've been instructing you about is still available.  You can download the latest build of the JavaFX Script compiler here.


JavaFX Script: Dynamic Java Scripting for Rich Internet/Client-side Applications
Immediate eBook (PDF) download available at the book's Apress site

Published at DZone with permission of its author, Jim Weaver.

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

Tags:

Comments

James Imber replied on Mon, 2008/05/12 - 12:02pm

I've been reading about JavaFX for a full year now. I think that they tried to market that thing way ahead of time. Even today, nothing seems to be ready. By June you'll get a 'preview release' of something.

I have nothing against JavaFX (it is great stuff) but, one year later, it doesn't seems to be quite ready yet for the masses.

Roger Voss replied on Mon, 2008/05/12 - 4:56pm

It would have been helpful if JavaFX would have refrained from inventing yet another scripting language and stuck with something that everyone doing RIA development already knows really well - like MXML and ActionScript3.

enrico donelli replied on Tue, 2008/05/13 - 8:40am

I like what I've seen about JavaFX, but I agree that at the moment it's only marketing, there's really nothing usable yet.

The documentation is very poor, many examples on the net are no longer valid with the new builds of the compiler, the tools are missing or in very early stage.

I'm also confused by the 3 versions: javaFx script, the openjfx compiler, and now the javafx sdk, as I don't understand which is the relationship between them?

Anyway, I really hope Sun will make it right, and wish JavaFX good luck!

 

Dean Schulze replied on Tue, 2008/05/13 - 9:47am

 

I'm disappointed with the long delay in getting a usable version of JavaFX out, and I share Enrico's confusion about the relationship between the various compilers, SDKs, etc. I don't know what you really need to build and run a JavaFX application, other than writing and running inside of Netbeans 6.1 with the JavaFX plugin. And now the plugin development has been suspended due to incompatibilities with the latest binaries. It just goes with evolution of a new platform.

 

In response to Roger, Adobe has given Sun a huge opening with their refusal to support Linux as a development platform and their incredible obstinance in not providing a 64-bit Linux runtime. It took 3 versions for Adobe to make ActionScript what it needs to be, and they've set the bar high for competing technologies like JavaFX. Sun must deliver a well architected JavaFX platform or they won't be competive. I hope that this long lead time and things like syntax changes are due to the JavaFX architects' dilligence in creating a platform that will be as good or better than ActionScript3.

 

They need to take the time and make the changes needed to assure that JavaFX is a compelling alternative to ActionScript3, or they will miss the opening that Adobe has given them.

 

Jim Weaver replied on Tue, 2008/05/13 - 10:18am

Yes, the versions of JavaFX Script as it has gone from prototypes to turning into a real product is confusing.  That's the risk of building things out in the open I suppose.  If you're interested in getting up to speed quickly on the version of JavaFX Script that is available today, I'd like to suggest three links. The first two links are to tutorials that I wrote for that very purpose:

Creating Rich Internet Applications With Compiled JavaFX Script Technology

Using UI Components in Compiled JavaFX Script Technology

The third link is to the compiled JavaFX Script category in my "Helping you become a JavaFXpert weblog"

Thanks,

Jim Weaver

Roger Voss replied on Tue, 2008/05/13 - 8:45pm in response to: Dean Schulze

[quote=dwschulze]

In response to Roger, Adobe has given Sun a huge opening with their refusal to support Linux as a development platform and their incredible obstinance in not providing a 64-bit Linux runtime. It took 3 versions for Adobe to make ActionScript what it needs to be, and they've set the bar high for competing technologies like JavaFX. Sun must deliver a well architected JavaFX platform or they won't be competive. I hope that this long lead time and things like syntax changes are due to the JavaFX architects' dilligence in creating a platform that will be as good or better than ActionScript3.

They need to take the time and make the changes needed to assure that JavaFX is a compelling alternative to ActionScript3, or they will miss the opening that Adobe has given them.

[/quote]

I'm not at all associated with Adobe, but I do feel compelled to correct the record a bit here:

Actually Adobe is very much looking to support Flex development on Linux. I don't think any of their Linux stuff is shippable bits just yet, but they have betas of Flex Builder, of course the Flex SDK, and an alpha or beta of AIR runtime that's been ported to Linux.

As to the 64-bit issue for the Flash Player - there is a 64-bit to 32-bit Firefox plugin adapter that can be used to run the 32-bit Adobe Flash Player on 64-bit Linux. This is the solution I use on 64-bit Ubuntu.

I do have a Flex developer that messed around with JavaFX some. One of his disappointments was the JavaFX script syntax. It was too discongruent with Java language syntax - they should have just used Groovy.

BTW, Java developers that take the time to look at ActionScript3 will see a rather likable language. It is compiled (not interpreted at runtime). It has static typing at compile time by default. It has classes, interfaces, and access protection of class members. It also has properties, events, and declarative data binding. Closuers are nice and very natural to use for managing async I/O service calls. The MXML script is naturally complimentary to AC3 - and makes intuitive sense to use when doing the view of the MVC pattern. Java developers tend to take to AC3 like ducks take to water.

--Roger

"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."

Yuri Magrisso replied on Wed, 2008/05/14 - 1:36am in response to: Roger Voss

[quote=Roger]

 I do have a Flex developer that messed around with JavaFX some. One of his disappointments was the JavaFX script syntax. It was too discongruent with Java language syntax - they should have just used Groovy.

[/quote]

 

You won't have to use JavaFX Script. I all compiles to JVM bytecode so you can use any JVM language. 

For me the most important thing about JavaFX is that it brings client-side goodness to Java in a way that is compatible with existing Java code. You'll be able to use any of it from plain ol' Java. 

Roger Voss replied on Wed, 2008/05/14 - 8:05am

Well, after the issue of JavaFX syntax, you then get into the programming model. JavaFX script has a higher abstraction level for doing Swing GUI programming. So if you don't use JavaFX script, you're then stuck with using Java and raw Swing.

A paramount advantage that Adobe Flex has enjoyed is a highly productive programming model. It's just not that hard to get powerful and pleasing results - especially relative to Swing coding.

Eric Z replied on Wed, 2008/05/14 - 9:32am

I have looked at Adobe Flex, and it does look great and I will probably be doing more with it in the future. I don't know much about JavaFX, but it's my understanding that it supports all java features including threading which Actionscript does not.  I realize that many applications don't need threading, but in my swing experience, i've done threading in slightly more then half my applications, and it's a very powerful tool available to the developer.

Roger Voss replied on Wed, 2008/05/14 - 11:38am in response to: Eric Z

With Java and C# .NET developers, these folks are used to doing asynchronous operations on threads they explicitly create and manage, and then use the utility mechanisms that both Swing and C# .NET each provide to marshal any data to the main GUI thread.

With ActionScript3/MXML based Flex apps, asynchronous operations revolve around doing I/O service calls or messaging interactions with the server-side.

So all the various I/O classes of the Flex SDK can operate in an asyncronous manner. For instance, the HttpService class has a send() method. Invoke send() and it will execute asychronously to the calling thread (which for Flex, will always be the main GUI thread of the app).

So to handle the result (or any error condition), you can use the closure feature of ActionScript3 language to supply a closure block that will process any result that is later asynchronously returned. The Flex architecture insures that your closure code that is invoked to process the result will actually execute on the context of the main GUI thread. Hence that code can safely interact with the state of Flex GUI objects.

A closure can be supplied to handle a successful business logic result, a business logic failure condition that is perhaps returned to the client - and a separate closure can be supplied to handle faults. Faults would occur because of, say, transport related failtures, etc. - such as not being able to connect to the destination server, I/O timeout, underlying socket errors, blah, blah, blah.

Closures are a very natural and intuitive means to program asynchronous class APIs.

The net result is that Flex architecture presents a simpler single-threaded programming model to the developer, while asyncrhonous I/O programming coupled with the language feature of closures, provides a means to create apps that are just as fluid and responsive to the user as are Java Swing or C# .NET WinForms apps. The user can continue to interact with the UI of the app, a progress indicator can be presented, and a cancel button that acutally works can be presented to the user.

So some of the same things can be accomplished in a Flex app but with a better and easier programming model than the explicit thread programming of Java or C# .NET.

Roger Voss replied on Wed, 2008/05/14 - 12:34pm

Just to put a fine point on this subject matter of Flex asynchronous style of programming, what a real Flex application will typically do is implement some variation of the MVC pattern (on the Flex client tier - not the server-side tier).

So the closure that processes the result of some asynchronous I/O service call operation (or a messaged pushed from the server-side via the Comet Pattern - ala BlazeDS), will typicall use the result data to go and modify the state of an object that resides in the client. That object would be some aspect of the data state that constitutes the Model from the MVC pattern.

Views onto the Model can utilize the AC3/MXML language features of properties, events, and declarative databinding to couple interactions with the Model.

A Model object can expose its state as properties. When I/O closure code modifies the state of Model objects, events on their properties will fire. Views can bind to these Model object properties such that Views will update whenever the underlying Model objects change due to, say, asynchronous I/O activity.

Views can use a controller to deal with feading view changes (which are usually due to user interactions) into the underlying model objects. Data validation will likely tend to reside in the View code. So view/controller interaction will concern itself more with feeding user-driven changes in view state (that have been validated) back into underlying model objects.

One upshot of the MVC pattern is that it now becomes straightforward to implement multiple views onto the same underlying model objects. Also, view code gets completely decoupled from I/O plumbing code, as that becomes partitioned into a separate aspect of the client app architecture.

Views may still need to be designed to say, disable a submit button after it's been pressed (so the user can't click it by accident or intent multiple times). Events could be used to signal to the view when the submit button can be safely enabled again. Likewise, there is the view programming involved for such things as showing progress indicators and/or cancel buttons when asynchronous I/O operations are actively being processed.

Comment viewing options

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