Sorry folks for things being so quiet around here recently. Behind the scenes the JavaFX team has been super, super busy cranking out JavaFX 2.0, and well, that takes a lot of time to ensure the quality and functionality is top notch. I hope to get this blog back to life over the coming months as more and more JavaFX 2.0 news begins to surface. We’ve definitely got a lot to talk about….but not quite yet 🙂
So, let’s get into the links!
- Richard Bair, Java Client Architect and blogger on this blog, was interviewed by Java Spotlight. He provides a lot of insight into JavaFX 2.0, both where it is now and where we are taking it in the coming months before the final release.
- Dean Iverson has blogged about using the JavaFX 2.0 early access release with Groovy/Griffon. He has even uploaded a YouTube video showing a brief glimpse of what he created. It isn’t much, but it’s exciting to hear of people using JavaFX productively in various JVM-based languages.
- Adam Bien blogged about JavaFX 2.0, in particular a smoke test around the installation, docs and launch experience. His thoughts are all very positive, which is great considering the early stage that JavaFX 2.0 is in.
- Finally, Eric Bruno has also announced that he has JavaFX 2.0 EA, and is very impressed by it. There isn’t much more content to this post, but he promises to continue blogging about his thoughts and findings as the weeks go on.
- Kyle Thayer let me know about IFCSoft. It is a data visualization program that uses Self-Organizing Maps to view multi-dimensional data. You can run the program at http://www.ifcsoft.org and get the code at https://code.google.com/p/ifcsoft/.
- Andre Hogenkamp has blogged about creating a JavaFX zoomable linechart.
That’s us for another week – and once again apologies since the last post – I’ll try not to do that again any time soon! Keep up all the hard work folks, and I’ll catch you all soon. 🙂
Thanks for the update. Can you update us regarding the license issues discussed here?
Unfortunately I’m just a developer in the JavaFX team, so I can’t really speak to licensing issues. I’m sure the people involved heard the feedback during the JavaFX 1.x times and are doing their best to ensure everyone is as happy as possible with JavaFX 2.0.
Thanks Jonathan. Let us know if you pick up anything.
i have just seen Adam Bien’s post via netbeans
The speaker said now they are targetting desktop on windows so is it correct to asume the javafx runtime will come bundled with the jdk or jre so it can be used on a desktop machine without any internet access just as current swing applications are deployed today?
I listened to the Oracle javafx 2.0 podcast (http://blogs.sun.com/javaspotlight/entry/java_spotlight_episode_16_richar). I am glad to hear that you are lobbying for first class properties in the Java language. I really hope that something makes it in for java 8. It’s ironic because most blogs say that the new javafx 2.0 is “back to java” and the immediate benefit is that you don’t have to learn a new VM language. However, in the same breath, people are saying that in order to use properties or object intializers you’ll have to use another VM language. You see the irony here. With properties I believe we can make Java the language a truly productive language for fx 2.0 .. not just second class citizen.
I am also curious if the 2.0 release will have some sort of external layout like flex and silverlight (mxml / xaml)?
I write all my JavaFX in Java, but as I pointed out above, different people have different preferred languages, and it is great that with JavaFX 2.0 we can now support all JVM languages so easily. I even presented at JavaOne on this very topic. Not having properties ain’t great, but it doesn’t suck either. If you went through writing UIs in Swing, then using JavaFX in Java feels very much the same.
Properties in the language is a very, very early discussion. I would be very surprised to see it in any announced release (i.e. Java 7 or Java 8), but then, of course, I’m not the one in control of these kinds of things. As Rich notes, we’re ensuring everything we do in JavaFX 2.0 is compatible (as much as possible) with upcoming improvements in Java, for example with closures.
Regarding an external layout file format, that is being looked into at the moment, and we do have some thoughts in this area, but whether anything happens in the 2.0 release hasn’t been decided yet. We’ll make more clear as soon as we can.
I agree not having properties is not the end of the world. However, all of javaFx’s major competitors have them and if we look at swing one of the things that it sorely lacked was properties. Swing is not to blame here, the java language just hasn’t caught up to it’s competitors.
I agree that we need some sort of external layout – I’m anxious to see what you guys come up with. I have always thought that flex’s mxml worked just fine and it has the obvious benefit of instant tooling support.
I am starting to see some posts with codes samples of JavaFx 2.0. In the presentation you posted above a lot has been said about trying to reduce boilerplate code. I was under the impression that JavaFx 2.0 was going to be built with fluent interfaces … that doesn’t seem to be the case. What kind of things are you guys looking at to reduce boilerplate?
Thanks for your updates , could tell us, has oracle announced any roadmap or plan regarding javafx for mobile. we are using javafx 1.2 jvm for window mobile for running j2me and java fx apps.Is oracle any plan to release it’s future versions or we assume it is dead.
I don’t believe any public announcements have been made regarding the future of JavaFX on mobile. Therefore, I have to unfortunately say nothing – sorry.
I’ve been using Swing for years, althought I haven’t touched JavaFX I’m very optimistic about JavaFX 2.0.
One of the biggest things that make Swing hard is the lack of a standardized set of properties (background/foreground colors, borders, fonts, etc…), which means you have to support multiple (and very specific) Look & Feels on your custom components, a real pain, and I think Nimbus (with the use of Painters) made it harder.
It would be fantastic if this gets addressed in JavaFX 2.0 (if not already in JavaFX).
In JavaFX, we aren’t exposing foreground, background, etc in the Controls API itself, in large part because of the experience learned in Swing. In Swing for example, the LAF might be using some complex gradient to draw a button. But all that is exposed is “setBackground(Color c)”. As a result, when you set the color, it makes the button draw a flat color instead of a gradient that matches the LAF, except in a different hue. In JavaFX, this is not the case. We use CSS to style the buttons, and have a few extensions which make this very convenient. For example, you can specify that you want a button’s “base color” to be red, and the complex gradient being used by the Skin will be derived from that color. In this way, by using a single line of CSS, you can instruct the button to use “red” but it will still look like it is a built-in part of the skin — with the same complex gradient, shadowing, and so forth.
There are a few blogs on how this worked in JavaFX 1.3 and prior, and those are still valid. We’ll have to make sure our docs team has some good examples ready to go for the 2.0 beta release 🙂