posts/2010/javafx-your-way-building-javafx-applications-with-alternative-languages/index

[JonathanGiles]

JavaFX Your Way: Building JavaFX Applications with Alternative Languages

https://jonathangiles.net/posts/2010/javafx-your-way-building-javafx-applications-with-alternative-languages/

[JonathanGiles]

Auto-imported comment, original author: Jan-Hendrik Kuperus Comment posted on: September 21, 2010

Thanks for the slides!

I do have some worries seeing your slides. For example, taking JavaFX Script away feels very awkward to me. The Java API looks like a good addition, but I think I'd prefer it being an extra feature. Leave JavaFX Script for the real UI-stuff, allow Java APIs for the integration points...

Any chance the JavaFX Script language as-is will be open sourced? Perhaps the community can pick it up and support it.

I'm going to let this sink in a bit, since this announcement is currently blotting out all other (possibly awesome) JavaFX features that were announced :)

--JH

[JonathanGiles]

Auto-imported comment, original author: Bill Robertson Comment posted on: September 21, 2010

I don't think this would require existing JavaFX Script to, "go away," however, providing much-needed glue to other languages is a good thing. It does create a bit of uncertainty though. What should be the direction for someone who wants to adopt JavaFX now?

[JonathanGiles]

Auto-imported comment, original author: SomeException Comment posted on: September 21, 2010

But if it will be true, does it mean that JavaFX Script will die or you want to develop Java FX Script and JavaFX APIs in the same time?

[JonathanGiles]

Auto-imported comment, original author: Carl Jokl Comment posted on: September 22, 2010

I would also have misgivings about the prospect of JavaFX script going away. Given one of the much touted features of JavaFX being the facility for binding directly in the language I am not sure how this would smoothly translate to any other languages.

It would seem a shame and a waste of a lot of peoples work to abandon JavaFX script. There is certainly a lot of buzz on the Java Posse Google group regarding the loss of JavaFX script.

[JonathanGiles]

Auto-imported comment, original author: clay Comment posted on: September 22, 2010

Why is access to closures on the pro list?

JavaFX supported closures extremely nicely. Java doesn't have closure support at all (I know several other JVM languages do)

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: September 22, 2010

The JavaFX Script compiler is open-source, and as my team-mate Richard Bair <a href="http://fxexperience.com/2010/09/javafx-2-0/&quot; rel="nofollow">mentions over at our blog</a>, we are very keen to have the community carry on this work - and to have it ideally spit out Java code that compiles against JavaFX 2.0. That would be ideal.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: September 22, 2010

The concepts of JavaFX remain the same, it's just the specific language that has changed. For someone interested in JavaFX now, learn more about JavaFX Script and JavaFX 1.3.1 APIs. When JavaFX 2.0 comes out you'll have a good headstart on everyone else, as the APIs should feel very familiar.

Of course, now that JavaFX is a Java API, you can also brush up on any alternative languages you may be interested in, as these languages now have just as much access to JavaFX as the Java language does.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: September 22, 2010

JavaFX Script won't die. The 1.3.1 release will continue to be provided, however any new developments and APIs will most probably only be appearing in the new JavaFX 2.0 releases.

This doesn't preclude what I mentioned in an earlier comment of the community picking up the JavaFX compiler. There are at least two ways this could proceed: 1) just adding features to the compiler and not being overly related to the official JavaFX 2.0 APIs, or 2) rewriting portions of the compiler so that it generates Java code that uses the new JavaFX 2.0 APIs. This would allow JavaFX Script to continue to be a viable language, and even make use of JavaFX 2.0 APIs.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: September 22, 2010

Carl,

You are correct that binding in Java is far less succinct than in JavaFX in the worst-case scenario. In other cases though it is still relatively nice. Of course, alternative languages, like those demonstrated in my talk yesterday, could be helpful in leading us back towards the succinct nature of JavaFX Script. Additionally, there is hope that the JavaFX Script compiler may become retrofitted to support compilation of JavaFX Script into valid JavaFX 2.0 code.

There really hasn't been a great deal of waste in our move from JavaFX Script. We have literally transliterated from JavaFX Script to Java, and this process did not take long. We took with us all of the lessons learnt, and retain all our knowledge of what is good and bad API decisions, etc. At the same time, we identified in the JavaFX Script APIs a lot of things we would like to tweak and improve upon, and this work now is giving us the chance to fix some of the rough edges we got stuck with in the JavaFX 1.x timeframe.

I would certainly not be worried about our direction - I think we've got exciting things ahead of us.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: September 22, 2010

When I was presenting this slide, I was saying "What are the good points about moving to Java". Of course, I'm very aware that JavaFX Script supported closures very nicely - I was just making the point that closures are slowly working their way into the JVM, and this helps with static footprint. This will be very beneficial to Java and alternate languages, and our APIs are being designed such that we can move from using anonymous inner classes to closures seemlessly.

[JonathanGiles]

Auto-imported comment, original author: Richard Osbaldeston Comment posted on: September 22, 2010

Will the open sourcing of JavaFX 2.0 components include a move into the JDK/OpenJDK source or will the curious web start only jars continue? Is that fair on the 3rd party langs to force them through web start / browser plugin just to bring up a UI?

[JonathanGiles]

Auto-imported comment, original author: Pavan Kumar Comment posted on: September 22, 2010

1: Will Javafx 2.0 components be embeddable in swingContainers

2: Will Swing in anyway benefit from Javafx 2.0

[JonathanGiles]

Auto-imported comment, original author: Fabrice Bouyé Comment posted on: September 22, 2010

Indeed, this roadmap does not cover one of the main roadblocks to the JavaFX API (besides its early-beta feel) which was the redistribution of the runtime and the offline deployment issues.

Additionally, I still feel puzzled by why are there still so few new controls planned for 2.0 compared to what’s already available to Swing + SwingX or other RIA APIs like Apache Pivot. As you told yourself, it looks like everyone is creating a TabView these days, and there is a good reason why: it’s because there is NONE in the current API. And let’s not talk about spinners, rich text display, etc.

But actually the main problem I foresee currently is the replacement of the FXD API as well as the Production Suite which was itself based on the subset of the JavaFX API and the scripting language. What’s the plan for that? FXD will now be a subset of the Java language instead or are there FINALLY any plans for the JVM to support SVG?

Other more immediate issues are what will happen to JFXtras developments and what about the JavaFX Composer support for 1.3 in NetBeans in the upcoming month…

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: September 22, 2010

Regarding the lack of controls - you have to remember that Swing didn't have everything to start with either - what we have in Swing is the result of many, many years of development. Full-featured controls do take a long time to develop, and there is a tonne of plumbing work that is being done at the same time (drag and drop, focus management, accessibility, global keyboard event management, etc).

Regarding FXD - that isn't going anywhere and is staying as a subset of JavaFX Script - we still intend to use it and are even interested in expanding its use in other use cases.

Regarding JFXtras - you'll probably hear more after the JavaOne session tomorrow.

Finally, regarding JavaFX Composer - I don't know sorry - I'm not involved in this project.

[JonathanGiles]

Auto-imported comment, original author: Galien Comment posted on: September 22, 2010

That history looks like throw out the baby with the bathwater, but that's it. As many javaFX developers we need to know if JavaFX is completely frozen in 1.3.1 until 2.0 (debugger, preview controls, etc...). Some people believed in javaFX, and had created real world applications with it.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: September 22, 2010

Galien, I've been keeping an eye on your discussion on developpez.net - thanks for calming down before commenting here :-)

I can definitely say we are not throwing the baby out with the bathwater. Like I mentioned earlier, we've directly translated our JavaFX Script code to Java, so we have lost very little time, and none of our awesome JavaFX technology (in terms of regions, the scenegraph, Node, etc, etc, etc). The only thing that isn't being progressed further is the JavaFX Script language itself, which of course continues to exist in 1.3.1 for the foreseeable future.

I'm not in control of the release plans, so I can't make any comments regarding them. Officially we've committed to a JavaFX 2.0 release in Q3 2011, as well as beta and early access releases in, approximately, Q1 and Q2 2011.

Responding to your comments on developpez.net, you have to realise that we try our best to keep you in the loop as much as possible. Despite your frustration about our announcements, the alternative option was to keep this quiet for longer and not announce anything until we were further progressed, but I think what we did was the best option. We've told you within a very short period from when we made the decision to move to Java - I hope you appreciate the very advanced warning - this isn't the normal approach of Oracle who prefer to keep information private and only comment on released software.

I'd love it if you continued to believe in JavaFX. We've got great technology in the pipeline - hopefully soon you might get a better understanding of this once the JavaFX 2.0 slides go online. If they don't go online soon I may ask Rich if he is able to directly put them online on our fxexperience.com blog.

[JonathanGiles]

Auto-imported comment, original author: Fabrice Bouyé Comment posted on: September 22, 2010

As far as I remember, in the days of Java 1.1.x, in Swing beta (you know the stuff Netscape gave freely for Sun back in ‘97), the only real component that was missing was the JSpinner which was added in 1.4. Except for that, there were no real “control addition” to Swing over the courses of the year (and I mean “new component”, not just bug-fix, adding font anti-aliasing, 2~4 takes on the DnD API, new useless LnF and another useless LnF framework, etc).

What mattered and sill matters as far as Swing is concerned is that Swing always lacked additional advanced dedicated controls as well as some additional generic controls to complete the currently available set. Oh, and that was actually one of the purpose of the not-so-successful SwingX project. I think I still have an RFE for a DirectoryChooser that dates from 2000 somewhere on the bug database + GFX (Romain Guy from the Swing team – he used to moderate our French Java forums) telling me in 2005 that such control was planned for SwingX with possible later integration to Swing. 2010… still waiting…

Here the issue is essentially the same, you (I mean the JavaFX PR, not you yourself) claimed too soon that FX was the Swing replacement (or Swing 2.0) without actually delivering anything concrete on the quantity, stability and usefulness (control-wise ; the effect and animation library is very good on the other side).

[JonathanGiles]

Auto-imported comment, original author: Galien Comment posted on: September 22, 2010

Thanks for the quick answer Jonathan. I understand the background aspect of changes in 2.0 API since I frequently look at JIRA and I've personally encountered issues with combining java and javaFX especially without annotations and threading policy. But I'm not happy with the communication, that's I wrote on the French side without retained :).

Like Fabrice says, earlier developers have to manage existing projects, that's for now my only concern.

Nevertheless i'm waiting Q1 to manage javaFX objects into a JEE container ;)

[JonathanGiles]

Auto-imported comment, original author: Jan-Hendrik Kuperus Comment posted on: September 22, 2010

I've read his blog and was indeed excited to see that you are encouraging this. Seeing the APIs you propose for 2.0, I think there's no problem making a JavaFX Script -&gt; Java compiler. Heck, I've been working on such a language for a game scripting engine, based on the JavaFX syntax :)

I'd really like to get involved :) Do you have any pointers for me to get involved?

[JonathanGiles]

Auto-imported comment, original author: William Antônio Siqueira Comment posted on: September 23, 2010

I'm interested too, please contact me.

I'm not so experient in compilers but I have time to learn :)

[JonathanGiles]

Auto-imported comment, original author: Pavan Kumar Comment posted on: September 23, 2010

A couple of queries...

1: Will Javafx 2.0 components be embeddable in swingContainers

2: Will Swing in anyway benefit from Javafx 2.0