Yesterday morning at JavaOne I gave a presentation called “JavaFX 2.0” (which will be repeated Thursday afternoon, and again October 5th at the SVJUGFX). There were several announcements both in the talk and in Thomas Kurian’s JavaOne keynote last night as well.
Yesterday we announced the roadmap for JavaFX 2.0. If you haven’t read through it yet you should stop now and go over and read the roadmap. There are a fair number of features going into JavaFX 2.0 and we’ve identified which will be available for the early access (EA) build, the beta build, an the final general availability (GA) build. There are some really great things on there such as fully hardware accelerated graphics pipeline (Prism), High-def media, a TableView control, CSS animations and layout, and much more.
In general, JavaFX 2.0 is a continuation of JavaFX 1.0. There is, however, one big change and that is with the language. JavaFX Script won’t be updated by Oracle for JavaFX 2.0 to run on that platform. Some folks in the community have expressed interest in taking on this task themselves — and I wholeheartedly encourage this. The JavaFX Script compiler is already open source. We haven’t worked out the details but I would imagine we’d rather add community members as owners of the project than have it fork.
Up to this point the only language that could be used to build JavaFX applications was JavaFX Script. I always felt this was a needless restriction. In addition, I felt that it was actually a bad thing for JavaFX Script the language for a couple of reasons. First, since all our APIs were in JavaFX Script, it meant that JavaFX Script had to be changed to be a good language for writing APIs, whereas it was originally designed to be a good language for scripting UIs. Sometimes this created a design tension. The compiler guys very wisely kept the focus on scripting UIs instead of writing APIs (which is why JavaFX Script was productive to use for building UIs), however it made our job on the platform team more difficult.
In addition, since the entire platform was built on the language, they didn’t have the freedom to fix certain issues in the language (such as initialization, which admittedly was mostly a problem for folks building libraries). My feeling is that decoupling JavaFX from JavaFX Script frees the language so that it can continue to evolve. Most languages have years to mature before becoming stable. JavaFX Script had a few months. It is to the credit of the compiler team and Brian Goetz especially that it came out as well as it did in the end.
So even though Oracle itself isn’t going to be committing to updating and shipping JavaFX Script in the JavaFX 2.0 timeframe, I sincerely wish to see it continue to evolve and improve. The same Binding capabilities that JavaFX Script enjoyed will be exposed as a library in Java, so any updated JavaFX Script compiler will have the tools it needs to implement language binding. Also, we’re working on the initialization issue such that object literals will still be possible (we’re considering several forms of initialization including the builder pattern).
In addition, I’m very excited to see what other languages can do / will do. Charles Nutter tweeted “Perfect storm: Mirah plus JavaFX APIs.” (Sorry I’m not a very good twitter person, I’m not sure how to link to the tweet!). I couldn’t agree more, I’m very interested in what Mirah would look like for building UIs on JavaFX. Especially if a variant of it could support bind in the language (which would be incredible). Already JRuby and Groovy work quite well with our current Java-based APIs.
Of course in the world of soundbites, what we see is “JavaFX is dead” (which is obviously not the case if you have seen any of Thomas Kurian’s keynote from last night), and “JavaFX Script is dead” (which is also not the case — it is open source and many of the strongest proponents have been in the community).
JavaFX is core to the strategy for rich client application development at Oracle. Simply put, JavaFX is the evolution of the Java rich client designed to address the needs of today’s and tomorrow’s customers. This is all about making Java dominant on the client. Jasper will post some videos of actual live demos we ran on stage at JavaOne (I hope he gets it up on youtube so it will be viral. Apologies if we use a flash player… for now!).
We have a lot of work to do. I think there will be critics and doubters along the way — but that’s fine. I welcome that. Judge us by what we ship, not what we say. I think JavaFX 1.3.1 was a great release (all of the stuff Jasper is showing in his demo is achievable with the APIs in 1.3.1 + the media and prism implementations for JavaFX 2.0). I’m really looking forward to delivering the next version of JavaFX.
Finally, we’re hiring! I’m looking for people who are talented, passionate, and have a good attitude. We have put together a really great team with a great atmosphere and we’re committed to engineering the best platform. If you think you’d be interested, drop me a line. We have positions in UI Controls, text, graphics, media, deployment, management, and more. Just drop me a line at my oracle email address and I’ll forward your info along into the system.
The first “roadmap” link in the text is broken – looks like you’re missing a double quote in your href…
Thanks Darren, that should be fixed.
Thank’s for trying to appease people who where learning javaFX script from since F3.
The fact is that JavaFX was a platform (language + API), so it will be just an API in the future.
Speaking about other language is, in my opinion, a way to minimize the big thing, because in theory all java API can be supported out of the box with other JVM languages (excepting for little JNI issues).
You told us (script supporters) that we have to continue the work, but you mention that the top level of the API was written in javaFX, for now, nothing is prepared for us to continue the work (API is not public), and many early javaFX developers needs stability after so much compatibility breaks.
Finally, you can hear the voice who says:
I invest hours, money in the language, my applications are in production, what’s next, seriously ?
The only thing I hope is that my customers does not care about J1 2010.
Regards.
As you may know if you track my old posts, I always urged you to add Java in the JavaFX game. It seemed logical to provide a path from Swing to JavaFX.
All I can say is “thank you”. Thank you to make the “Swing 2” comcept (as you mentioned last year) a reality.
I can’t wait to see the JavaDoc and dream about the release.
Again, thank you.
> Just drop me a line at my oracle email address and
> I’ll forward your info along into the system.
it is hard to find your email 🙂
is it firstname.lastname@oracle.com ?
You got it 🙂
I was trying to send you an email the way Peter did, but I’ve got an delivery error report. Can you provide me with your email , so I could “drop you a line” 🙂
Thank you.
JDK7 + JDK8 + JavaFX 2.0 API = very big promise.
I’ll believe it, when I see it. Because, unfortunately, Oracle isn’t very good at keeping promises.
I’ve always been a big fan of JavaFX and its language. And it saddens me particularly seeing all these marvelous things go to waste, just for the sake of the short-term money making platitude.
Amen.
I don’t think there is anything short-term in the thinking around the JavaFX plans!
Not the for API, no. I was referring to the language and why in my opinion it has been decommissioned. However it looks to me there are many “if’s” before JavaFX API 2.0 is a reality.
We’ll see where it all stands next year. Wishing you all the luck !
I don’t understand why you’re saying that Oracle isn’t very good at keeping promises. When was the last time that Oracle didn’t keep a promise? They promised to keep Java and they did. They promised to keep MySQL free and they did.
I can’t remember a single occasion when Oracle didn’t fulfill its promises towards the community.
Apache Pivot (Swing++) is now miles ahead of JavaFX, plus I can download ALL of it. I guess these guys where right all along and have the proof, great framework with many controls as well as immediate AND retained (scenegraph) rendering.
Yes, the JavaFX controls are to be open sourced, big deal, because Oracle has the core and it will never be open source. If control developers want to keep putting more effort after the great effort they have already seen go to waste that is their choice. Just remember that Pivot can always use your help too and that your effort will not be smashed by any corporation.
First lesson, last lesson.
That is not true. Apache Pivot is a simple toolkit. But it doesn’t even come close to JavaFX or even Swing.
Lets get something straight, JavaFX has been the simpleton here not Pivot. Looking under the hood of Pivot you can see that there is an incredible wealth of good code, not the endless tripping over itself that JavaFX made everyone endure.
Pivot addresses many aspects of modern RIA development very well. Even when JavaFX 2.0 finally arrives in the future its components will just nicely fit into the substantial foundation that Pivot has already provided. Pivot 2.0 will be released within a month or so, mean while JavaFX is vapor.
No flame wars on my blog. Another step and the big censor stick is coming out. Rational discussion is, of course, always encouraged.
JavaFX is incredibly powerful in places Pivot cannot be (ie: graphics capabilities) because Pivot relies on AWT / Swing and there are inherent limitations there (such as the single-thread rendering model shared with the UI thread). Pivot meanwhile has done a lot of really great work over the past several years in areas where JavaFX is still developing such as in the Controls and supported infrastructure.
There’s no need to be starting a flame war here. There’s no JavaFX vs. Pivot discussion happening, so lets not start one. Take it elsewhere.
Richard, thanks for the clarifications :).
You guys have great plans for JavaFX!
I’m sad JavaFX Script isn’t continued by Oracle, but the only thing I’m really sad with JavaFX is that I can’t test the new way to build JavaFX applications, worse, it will takes about 10 months :o. I liked JavaFX since the first script I wrote, before I was a Java Swing fan 😀 I never left JavaFX even the hard moments and all the JavaFX team did the same, no one dropped JavaFX because it was not so popular. Some guys dropped JavaFX for others personal things, not for not believe the technology…
By other side, I’m happy with JavaFX annoucements, thanks for the hard work from the JavaFX team!
I would candidate to JavaFX jobs you said, but I’m still a new developer (Junior). I would do that just to keep myself programming in Java/JavaFX all the day 😛
[]’s
I was hoping for a bit more info on the bindings and clarity on Swing integrations etc.. Will the bindings be reusable by Swing & generic Java at all? I’ve not seen anything along the lines of language level properties or a new bean model which is where the previous beanbindings incarnation was left off. Looking at the deferred features http://www.dzone.com/links/r/list_of_jdk_7_features_deferred_to_8.html jsr295 is missing, is this because the new JavaFX bindings will solve the issue for both Swing & JavaFX APIs or because Swing bindings has been permentley shelved? Is there another session by the Swing team that might answer some of these lingering questions? over what JavaFX 2.0 taglines (Swing++ and Swing 2.0) means for the future of the existing API. I know Alexp isn’t present to answer any questions from the Swinglabs guys.
Also wondered about the Prisim plugin will this be a completely separate plugin that developers will have the option to request or will it be added the current plugin and will kick-in automatically if the h/w requirements can be met? Is there any chance Swing/Java2D could partake in Prisim enhancements more directly? or are the graphics modes hopelessly incompatible.
I was very, very happy to read the roadmap especially for two things: that the APIs will be usable from Java (and thus Clojure) and that a rich text system will be available! Woo-hoo!
This is a good and bad news. I´m playing with JavaFX since 1.2 version and the better thing about the language is the script sintax. I just can´t undertand why Oracle cannot maintain both script and java sintax.
Well. Better than nothing….
I’m the same as you.
It’s a pity that Oracle couldn’t continue JavaFx script? But why on earth, for money saving or for technical reason?
It’s too long to wait JavaFx 2.0 for us. Why not release JavaFx 1.4 with some more control, such as the Table view? Is it too difficult to do that? If so, the JavaFxscript should be dropped certainly? If not, the JavaFx team may pay more attention to the agile world to release more times with a long plan based.
Maybe it’s the long-term release cycle that makes JavaFxscript dead but not by oracle.
Hope the JavaFx script long live.
A new track is open to all developers.
Like Maycon, I love JavaFX at first sight. It´s simple, direct and give to programer/design a freedom that Java don´t give.
This time lapse between JavaFx 1.3 and 2.0 may be a “cold water” in delvelopers flame and passion to the technology.
I use JFX integrated with Java in several apllications (web and desktop) and now I’m affraid about future, because 9-11 month wait is a long time to tecnology and development.
How we integrate ours JavaFx scripts, libs and aplication to this new aproach (JavaBeans) with small impact ? All community is waiting for this answer.
Regard to all JFX fans.
Hi Richard – Thanks for this update. What is happening with a) the large(?) investment in the “designer tool” and b) Slim Shady DS? Thanks
I can’t comment on stuff we didn’t announce at JavaOne. Sorry!
Maybe you can answers this question.
I´m almost starting to build an reasonable application (for desktop and web profile) and after the Javaone, javafx was the perfect choice, but now i´m huried about start to write in JavaFX Script code. The actual JavaFX script sintax will work on 2.0 compiler?
I would imagine in some ways it would continue to work. You’d have to ship the compiler’s runtime. The animation syntax would refer to an animation engine that is different (and probably won’t work). But the core language itself should still work as before. You won’t be able to bind to Java-based APIs (because the JavaFX Script’s idea about how to do that will be different from how we do it in 2.0). So while the language itself would still work and could work with the java APIs, most of the value-add won’t be there.
How about JavaFX running in CDC and CLDC environment? Do you thing that will be a new CDC and CLDC version?
I cannot comment on that at this time, sorry!
I have to say that I’m quite excited about the announcement. Admittedly, I’ve only dabbled in JavaFX (nothing commercial), so I don’t have much to lose from the dropping of JavaFX Script. I liked a lot of what the language provided; however, what I really wanted was to be able to write JavaFX in Scala.
Since JavaFX in Scala is now more likely to happen, I’m pretty happy.
It seems to me that Oracle have made the right decisions. JavaFX Script is problematic since most people will mix Java and JavaFX in large applications anyway and this isn’t as easy as it should be.
Open-sourcing JavaFX script and giving it to the community makes it another language for the JVM, not necessarily tied to JavaFX. It gives it parity with Groovy, Scala, Clojure, etc, giving people the choice to use it or not for their JavaFX applications. My guess (for what it’s worth) is that it’ll die a slow death as developers favour Groovy and Scala (or Clojure for those who think the world can’t have too many parentheses).
Richard there is a new programming language on the block called Visage (http://code.google.com/p/visage/). Visage is heavily based on JavaFX Script. Essentially it is a fork of JavaFX Script.
I can understand why the move was made to fork JavaFX Script since some people thought that Oracle may still be controlling the JavaFX Compiler project, even though Oracle has dropped support for JavaFX Script. Also a name change is needed since JavaFX Script isn’t going to be tightly coupled with JavaFX 2.0 when it is continued.
Too many people have made a serious commitment and investment in JavaFX Script for it to go to waste. A migration from JavaFX Script to another JVM language is quickly proving to be very difficult for a significant number of people. The biggest danger is that unless people are provided with a transition path (not a migration one) then there is a very high chance that they will switch to a different platform (eg from Java to .NET) :(. This is the last thing that Oracle wants so it will be interesting to see how they respond to this situation.
With Visage being created it will provide a reasonably smooth transition for people that have used JavaFX Script, but don’t want to use another JVM language. In my own opinion it will be enough to avert the current situation. Oracle need to learn important lessons from dropping a highly effective technology that was used by a significant number of individuals and businesses, with great success.
Two factors for the positive acceptance of JavaFX seem to me to be having Open Office re-written in JavaFX, and having a first class JavaFX plugin for IntelliJ IDEA.
It takes a long time to compile a large Java/JavaFX project in NetBeans. IntelliJ IDEA just compiles what you’ve changed. While the first factor might be symbolic, the second is anything but!
Larry Ellison promised Open Office. Is that still going to happen? Is being able to develop with IDEA in jepody? I hope not. If Larry has broken his promise then perhaps he should fund development of the plugin. Does that sound fair enough??
What about the distribution issue: Is javafx 2.0 going to be part of the JRE?
Currently the distribution is number 1 issue of javafx according to the Official Javafx UserVoice: http://javafx.uservoice.com/forums/33584-official-javafx-feedback-forum/suggestions/403105-allow-us-to-distribute-the-javafx-runtime-binary
What are the plans here?
Best
Fixing deployment is a huge priority. We’re definitely very aware of the distribution issue.
that sounds good…hopefully you’ll manage to fix this issue within the 2.0 beta timeframe(?)
Looking forward to see the changes…and btw will someone change the status of this issue in the javafx user voice: http://javafx.uservoice.com/forums/33584-official-javafx-feedback-forum/suggestions/403105-allow-us-to-distribute-the-javafx-runtime-binary
It is ‘under review’ for a longtime now…’planned’ status should be more appropriate I guess
Best
Will the ability to embed browsers promised in V1 but never delivered show up V2?
lets hope they keep their word this time