randahl's Blog
JavaFX 2.0 is back on the Mac
Posted by randahl on October 5, 2011 at 3:58 AM PDT
After Oracle announced JavaFX 2.0's return to the Mac earlier this week, I spent some time porting our previously Windows-only JavaFX application back to the Mac. It was surprisingly easy. I found a few bugs, but they turned out to be quite easy to work around. Here's what to watch out for, if you are porting...
1. The Mac API does not use stage.setVisible(true) like the new JavaFX 2.0 Windows API does, instead Mac uses the less flexible (parameterless) stage.show().
2. In the Mac APIs the builder classes are not yet moved to the new builders package, which means we had to change our imports back to statements like import javafx.scene.shape.ArcToBuilder;
3. Unlike the Windows API, the Mac API requires that you remove the leading '/' character in style sheet URLs as in scene.getStylesheets().add("styling/cool.css");
4. The default caspian style-sheet uses blue default buttons in the Mac API, whereas the latest caspian style-sheet on Windows has bright silvery buttons.
Other than that, the combination of the world's best UI framework and the world's best OS is an absolutely amazing development platform.
You can download the new beta for Mac from javafx.com/downloads
Related Topics >>
Blog Links >>
- Login or register to post comments
- Printer-friendly version
- randahl's blog
- 2306 reads
JavaFX eats HTML UIs for breakfast
Posted by randahl on September 18, 2011 at 10:15 AM PDT
These are the days to be a Java UI developer! For so many years I have dreamt of Java’s return to the client side, and now – at long last – the developers at Oracle are making this dream come true.
Since the late nineties I have been developing a large number of both web based and swing based UIs, and it has always felt like a hard choice between two imperfect sets of technologies. But now – thanks to JavaFX – the days of technological compromise are over.
JavaScript – the slow productivity killer
While my web-based applications would work on more devices, require no installation, and integrate perfectly with the web, too much time was spent debugging the UI and fighting off all those perpetual cross-browser differences. Countless hours were spent trying to make the UI perform and deliver a user experience which ultimately only seemed like the real thing; and as the feature requests from end-users got more demanding in each consecutive project, so got the debugging. “Hey, can we have drag-and-drop? Hey, can we load these data from the desktop? Hey, could we have multi-tasking support?” – Indeed, end-users know the benefits of real native applications – they just do not realize that building a feature-rich UI experience with JavaScript is like building a space shuttle out of papier-mâché... and why should they?
Swing – trusty but overweight
Swing-based Java clients had many benefits over web clients, but at the same time introduced a whole range of new problems. Yes, ditching JavaScript in favor of using real Java all the way from the data access layer to the UI had a sublime impact on code reuse, debug-ability, test-ability, stability, experienced performance, and – most importantly – cost. Still, requiring end-users to download and install applications which were humongous considering the download speeds at the time and Swing’s ever delayed support for HTML beyond HTML 3.0, really put a limit to the kinds of projects which the technology could be applied to. And when customers saw all the luscious visual tricks Adobe pulled out of the hat with Flash, the non-animated, two-dimensional Swing UIs just looked like a steam engine in the space age.
JavaFX – even better than the real thing
JavaFX 1.0 came off to a slow start, mainly because of the surprising decision by Sun – the Java company – to require all Java developers to use a different language than Java when developing the UI, JavaFX Script. I think, Oracle’s most brave and insightful decision after the acquisition of Sun, was to take all the promising, cool features of JavaFX and unleash them in Java with JavaFX 2.0. Gone is JavaFX Script, and now everything Java is also JavaFX and vise-versa. Every single line of code you write can be reused – in all layers of your application. Just imagine the productivity increase your company will harvest from that!
And feature-wise the days of hard compromises are over. Now your compiled, type checked, automatically unit tested, truly object oriented, highly reusable, component-oriented program is fully capable of rendering real-time, ultra-smooth, CSS styled, vector based 2D and 3D animated contents mixed with video, sound, and (to top it off) HTML contents. – That’s right... all the things you could do in a web client with HTML, you can now do with just a single component in JavaFX (the WebView). And there are hundreds of other rich components in the feature set – if you can conceive it, JavaFX can deliver it.
Getting Started
My company, ROCK IT, is developing an innovative security product for the private sector, and being an Oracle Java partner, I have been using JavaFX since the early access version was released in January. It really is a completely new UI paradigm and it takes a bit of getting used to, but it is refreshingly innovative and powerful. It truly feels like taking Flash, Swing, and the traditional web technologies, and merging everything into a single, clean, well thought out technology, that matches the needs of the UI layer with perfection.
I am absolutely convinced the developers at Oracle have hit bull’s eye with this technology, and now – at long last – Java lets us creative developers deliver the powerful, rich user interface experience customers want.
If you still have not tried JavaFX, I warmly recommend you get started. The main starting point is http://javafx.com. The JavaFX community forum at http://forums.oracle.com is a great help, and also Jonathan Giles’ blog at http://fxexperience.com/ is a great source of inspiration.
Related Topics >>
Blog Links >>
- Login or register to post comments
- Printer-friendly version
- randahl's blog
- 8272 reads
Comments
Not only is there no ETA for the Mac and Linux versions but ...
by xolotl - 2011-10-01 04:34
Not only is there no ETA for the Mac and Linux versions but now I see that the delivery of the web component has been delayed, too. So, no, this is not ready for prime time. Sorry. Maybe in a few months.
I want JavaFX to succeed, too, but it's not there yet: rich text, web page rendering and platform neutrality are all must-haves, not nice-to-haves.
I really want to use JavaFX. I played with 1.3 a ...
by rhysp - 2011-09-22 09:15
I really want to use JavaFX. I played with 1.3 a little and 2.0 solves a lot of problems. However, I can't persuade anyone that it's a valid choice for apps running in a browser.
Despite the pain of HTML/JavaScript/CSS web applications, too many Product Managers insist on it as a platform because they know it will be deployed. Once you say, "How about a Java-based UI?" they just laugh. Flash may be acceptable; but HTML 5 seems to be the platform of the future. But where are the tools?
And what about tablets and phones? HTML 5 will work, but not JavaFX. If Oracle want JavaFX to be anything but a niche platform, they need to find a way to get it on devices, corporate PCs and conumser devices.
Good luck on that one!
Which really just makes JavaFX a replacement for Swing.
Now it seems to me that what browsers need is a general-purpose, language-independent, open Virtual Machine to replace JavaScript. The JVM wouldn't fit the bill (too much baggage), but Oracle now have resources and experience to be able to build Virtual Machines. Being at the centre of that and any tool chains could be highly profitable. What's more, a JavaFX-like system that ran on said VM could be very cool indeed.
Not that it'll happen; but I can dream!
If by "too much baggage" you mean the size ...
by randahl - 2011-09-22 11:15
If by "too much baggage" you mean the size of the JRE plugin or the size of Java application UIs, I'd like to add a couple of observations:
1. Back in the late nineties when applets failed miserably, the average bandwidth here in northern Europe was 56 kbit. Today it is more than 1.000 kbit. In other words, the applet which took two minutes to download will now take 6 seconds - on average.
2. If Oracle manages to complete the modularization of Java (project Jigsaw), then the download time of the JRE itself will be dramatically reduced.
3. The major download size contributor in the games and other Applet content I made for lego.com back in the day was GIFs and JPGs. JavaFX is all vector graphics which take up virtually no space in my jars.
4. In Denmark where I am from, the JRE is already installed on nearly each and every household computer, because it is required when using the official Danish personal identification system, NemID, which is used when logging in to your home banking system, local city services, state tax services, etc.
One of the main benefits of Java is the fact that it's ...
by Daniel15 - 2011-09-21 20:23
One of the main benefits of Java is the fact that it's cross-platform. If JavaFX will only work on Windows in the initial release, what is the point of even using Java? If your app is going to be Windows-only, you may as well just use C# and WPF to make a fancy interface.
NEXT: JavaSE + JavaFX + JavaME MIDP 2.0 Compatybility layer ...
by m1k0 - 2011-09-26 01:03
NEXT: JavaSE + JavaFX + JavaME MIDP 2.0 Compatybility layer FOR MOBILE PHONES!
So if you were starting a new project would you use JavaFX ...
by andrewmccallum - 2011-09-19 19:52
So if you were starting a new project would you use JavaFX or Swing or both?
Like if you were writing NetBeans now, could you do it all in JavaFX? Or is it not approriate to do it in JavaFX because NetBeans doesn't have a lot of animations?
Although you can embed Swing components in your JavaFX code, ...
by randahl - 2011-09-20 00:20
Although you can embed Swing components in your JavaFX code, I have not found a need to. Remember, JavaFX is a complete UI framework, and it has its own set of UI components (labels, text fields, etc.).
Now, NetBeans is a very untypical example, because it relies on a very complex application framework, and NetBeans has advanced requirements like dockable windows (which JavaFX does not support yet) and advanced rich text editing (also not supported yet).
On the other hand, if your application only needs typical UI components, like the ones already found in JavaFX, choosing between Swing and JavaFX is more a question of project resources, team skill level, and timeframe. Learning a new UI framework is not trivial.
I recommend you compare your feature requirements with what is already possible with JavaFX. Have a look at download.oracle.com/javafx where you will find all the documentation you need. Also, jfxtras.org has a large set of add-on controls.
And finally, if your product is expected to be around for years, think of what you will do, when new requirements show up a year or two from now. I recall what happened to AWT once Swing came out – everyone's focus moved to Swing, meaning all the new cool UI features of Java were Swing based, and AWT practically died. The same thing will happen to Swing, as soon as JavaFX gets a foothold. Sure, Swing will be around for many years to come, just like AWT is still a part of the JDK, but my anticipation is, the evolution of Swing will die out.
I experimented with 1.3 and from what I can tell I will like ...
by carljmosca - 2011-09-18 15:00
I experimented with 1.3 and from what I can tell I will like 2.0 but I find it hard to believe it's still, at least for the time being, Windows only.
Actually, I am developing on a Mac. The early access ...
by randahl - 2011-09-19 02:48
Actually, I am developing on a Mac.
The early access release works just fine on the Mac, so if you are a Mac user, just buckle up. After the beta came out, the Mac libraries have not been updated, so at the moment I am compiling and building on the Mac, and testing all my non-UI code here; in my particular case, I needed a bug fix which was solved in the recently release JavaFX beta, so I had to upgrade, and now I am debugging my UI code using a Windows laptop. This is actually a good thing, because the PC laptop closely matches the end-user system requirements by having a much more modest graphics card than my Mac Pro. There is no official release date for JavaFX 2.0 on Mac and Linux, but I am guessing those releases cannot be far away, since the early access release was already multiplatform. From the official JavaFX FAQ:
JavaFX 2.0 will be fully supported on 32-bit and 64-bit versions of Microsoft Windows XP, Windows Vista, and Windows 7. Early Access versions of JavaFX 2.x for Mac OS and Linux will be made available at a later date, but support for these platforms will not be included as part of the JavaFX 2.0 final release.
Your guess is as good as mine, but that sounds a lot like a multiplatform commitment to me – I think the JavaFX project just realized that Rome was not built in a day. To ensure high quality on all platforms takes time, so in my opinion, their strategy to hit the most popular platform first is quite sound.
Can you explain the last part of this ...
by bphillips - 2011-09-20 06:23
Can you explain the last part of this statement:
JavaFX 2.0 will be fully supported on 32-bit and 64-bit versions of Microsoft Windows XP, Windows Vista, and Windows 7. Early Access versions of JavaFX 2.x for Mac OS and Linux will be made available at a later date, but support for these platforms will not be included as part of the JavaFX 2.0 final release.
Our Java shop develops on a mix of Mac and Linux machines. My understanding from the above statement is that JavaFX 2.0 final release will not be supported on Macs and Linux. So I don't see our programmers adopting this framework.
I don't agree that this a good decision at all. To ...
by xjh - 2011-09-19 04:54
randahl wrote:
Actually, I am developing on a Mac. JavaFX 2.0 will be fully supported on 32-bit and 64-bit versions of Microsoft Windows XP, Windows Vista, and Windows 7. Early Access versions of JavaFX 2.x for Mac OS and Linux will be made available at a later date, but support for these platforms will not be included as part of the JavaFX 2.0 final release. Your guess is as good as mine, but that sounds a lot like a multiplatform commitment to me - I think the JavaFX project just realized that Rome was not built in a day. To ensure high quality on all platforms takes time, so in my opinion, their strategy to hit the most popular platform first is quite sound.
I don't agree that this a good decision at all. To postpone support for the other two IMPORTANT platforms is really an odd decision. The company I work for did not consider JavaFX 2.x for a future project because we simply don't know when and how good support for the other two platforms will be. This is really unfortunately because I really like JavaFX 2.x (and we have used JavaFX 1.x before).
I agree with you xjh. By only delivering on a subset ...
by scirka - 2011-09-29 11:30
I agree with you xjh. By only delivering on a subset of platforms Java is forgetting its "Write Once, Run Anywhere" promise. I was excited to see the JavaFX 2.0 announcement and was hoping to get a jump on doing some experimentation only to find out that it wasn't supported on OS X - my dvelopment platform of choice.
Comments
That does not seem very portable to me. Until JavaFX offers ...
by pjmlp - 2011-10-05 08:51
That does not seem very portable to me.
Until JavaFX offers true portability across Unix, MacOS and Windows it won't be used in our projects.