As I'm converting the examples and exercises in my JavaFX Script book to compiled JavaFX Script, I'm making note of the kinds of changes required. I plan to post these notes in a more formal way to the Converting to the New Syntax PlanetJFX Wiki entry that Tom Ball created, but I want to give you a brief synopsis of some notable changes at this point:
- operation and function have been combined into just function. The body of the function is now supplied at the location in which it is declared (see Converting to New Syntax post).
- attribute initializers and replace triggers are now placed in the attribute declaration, rather than in separate areas (again, see the Converting to New Syntax post).
- There is a feature in replace triggers that isn't in the Converting to the New Syntax post yet. This feature enables you to get the original value of the attribute in case you want to veto the replace.
To see examples of the changes noted above, please take a look at my No Need for Setters and Constructors in Compiled JavaFX Script post. Continuing on:
- named instances (for example white:Color) are now defined as static (class) variables (for example Color.WHITE). See my Happy New Year post for examples of this.
- Access modifiers (private, protected and public) are respected now.
- Object literals that don't require attributes (e.g. MenuSeparator) require curly braces in compiled JavaFX Script, where interpreted JavaFX Script is more forgiving (doesn't require curly braces).
- Have to explicitly specify object literal names that were implicit in interpreted (like this example using the accelerator attribute of the MenuItem class). The first example works in interpreted JavaFX Script, but the second one is necessary for compiled JavaFX Script:
MenuItem {
text: "Place Word Randomly..."
mnemonic: R
accelerator: {
modifier: CTRL
keyStroke: R
}
}
MenuItem {
text: "Place Word Randomly..."
mnemonic: KeyStroke.R
accelerator:
Accelerator {
modifier: KeyModifier.CTRL
keyStroke: KeyStroke.R
}
}
- Functions in classes that you override in other classes (e.g. CompositeNode) requires explicit return type (e.g. function composeNode():Node)
- Bi-directional binding requires "with inverse" at the end. For example:
TextField {
value: bind model.firstName with inverse
}
- The compiler is strict about assigning a Number variable to an Integer variable (because of possible loss of precision). Use the intValue() function of the Number variable to convert without a compiler error.
Here are some changes in which you can reference the Compiled JavaFX for - Is it an Expression or a Statement post:
- The syntax to declare a sequence is square brackets [] rather than an asterisk *.
- for and foreach have been combined into for, which can be used as a statement or an expression.
- Functions that don't return anything are declared with :Void at the end of the function signature.
Here are a few more changes/additions I'd like to mention as well.
- Compiled JavaFX Script is an expression language, so you can take advantage of features such as sometimes omitting the return statement in a function. See the Express Yourself in Compiled JavaFX Script post for details.
- The if/else expression in compiled JavaFX Script is just like Java and JavaScript: parentheses are required around the conditional expression, and curly braces are not required. Because compiled JavaFX Script is a block expression language, an if/else expression has a value and therefore behaves like the Java ternary operator. It can also be used as a statement, which behaves like the Java if/else statement. Please see the Compiled JavaFX if/else - Is it a Statement or an Expression post for details.
- Functions are first-class objects, and closures are a feature of compiled JavaFX Script. See the Achieving Closure in Compiled JavaFX Script post for details.
I think that you'll enjoy moving over to compiled JavaFX Script (when you're ready -- I'm not rushing you). It still has some unimplemented features (e.g. insert before/after, and delete predicates in sequences), and some refining to do on the UI side, but it's feeling pretty good right now. It would be great if you'd begin playing around with it and be part of the JavaFX Compiler community that identifies and reports bugs. There is an issue tracking system called JIRA that we're using for this purpose.
Regards,
Jim Weaver
JavaFX Script: Dynamic Java Scripting for Rich Internet/Client-side Applications
Immediate eBook (PDF) download available at the book's Apress site
Thanks for the explanation Jim, believe when I say I'd like to see jfx reach its full potential, right now it seems to me it is still in the pupae stage, I want to see the tools! =) The recent keyframe/time upgrades are great and I look forward to see more info on animations and custom extensions.
On the other hand GraphicsBuilder is also in its pupae stage, I'd like to finish static effects before focusing in serious tool support, and who knows perhaps a jfx/gfx translator which works both ways.
Thanks,
Andres
Posted by: Andres Almiray | January 08, 2008 at 12:57 AM
Good to hear from you again, Andres. There have been some changes, but the compiler team has been very careful to keep the language simple and elegant. The declarative parts of the language and UI have had very few changes, and the classes/functions side of it has in my opinion been simplified. For example, operations and functions have been combined into just functions. Also, "if/else" used to have two forms of syntax: one for statements and one that replaces the ternary if-then-else operator. Another simplification is the fact that triggers and initialization now are located where the attribute is declared. Part of your perception may be a side-effect of my focusing on things that have changed, and on things like closures and block expressions.
By the way, I've been enjoying your http://www.jroller.com/aalmiray/ blog, and am looking forward to the day that JavaFX Script has a graphics builder as cool as the one for Groovy that you've been focusing on!
Thanks Andres,
Jim Weaver.
Posted by: Jim Weaver | January 07, 2008 at 06:14 PM
Jim, I've been following your blog for quite a while, so I'm a bit sad to say that it looks like F3 has endured a mutation (note I don't mean evolution) from a Ruby/Python easy-to-learn language to a preview of what may be jdk7 since it was rebranded to JavaFX Script, or am I missing something?
Posted by: Andres Almiray | January 07, 2008 at 05:25 PM