Continuing with yesterday's core topic of JavaFX, there's an interesting article about JavaFX mobile applications performance on the Sun Developer Network: Michael Heinrichs' JavaFX Mobile Applications - Best Practices for Improving Performance. My thanks go out to Terrence Barr for pointing this out, as I hadn't noticed it previously.
Michael's article starts out with a strong disclaimer stating that the performance tips he describes:
are true for the current version of JavaFX Mobile at the time of this writing, which is part of the JavaFX 1.1 SDK. In future versions, the behavior may change, and so the current undesirable performance of the mentioned artifacts will be optimized away or at least significantly improved. Everything I am writing about here is a snapshot for the current release only.
This is an important statement, given that JavaFX is such a new technology. Given time constraints on developers, and the need to get a new technology out to the community as quickly as possible (this is especially the case in a situation where a formidable competing technology is already well-established), the first phase of development of a new technology necessarily focuses on configuring the fundamentals of the framework and providing a core feature set. It's like the first introduction to the developer community has to be:
"Here's a new technology. It has thisfundamental design structure. Here's what it can do now. Based on the underlying design and initial feature set, you can seewhat will be possible in the future."
No, in the case of JavaFX, in my opinion it would have been a mistake to delay the initial releases pending significant performance optimization. This had to be gotten out to the community as soon as possible, given the prevalence of the (non-Java) competitors.
So, Michael Heinrichs provides pointers to mobile applications developers on how to improve JavaFX performance, with the strongly stated caveat that perhaps some of the techniques he lists may not "work" in the future (because the underlying issues will have been optimized away within the JavaFX framework itself).
For today, for the JavaFX Mobile that is part of the JavaFX 1.1 SDK, the best practices for improving mobile application performance include (click on the links to see Michael's full explanation and code samples):
- Avoid unnecessary bindings - "Very complex dependency-structures tend to impose a severe penalty on performance and footprint."
- Keep the scenegraph as small as possible - "The more elements a scenegraph has, the more communication is required."
- Use simple shapes instead of images, but use small images instead of complex shapes - "sometimes using shapes is better, sometimes using an image is better. To help making the right decision, here are some points one should consider"
- Use the prescaling functionality - "If an image needs to be scaled and the scaling factor does not change later, you should use the prescaling functionality."
- Use background loading - "The class
Imageprovides a useful but easily overlooked feature: the ability to load images asynchronously in the background."
- Define variables with
var(make them script-private) - "When defining instance variables, it is good practice to limit the accessibility as much as possible."
Number- "Operations on integers are always faster than operations on floating-point values."
- Use functions of class
Sequences- "The class Sequences in the package
javafx.utilprovides a large number of useful functions for dealing with sequences."
A lot of these points actually apply to optimizing performance with almost any user-facing software engineering technology. The key issue for mobile applications, though, is that you're hardware platform has limited capability. Therefore, optimizations that wouldn't necessarily be noticed by the users of a desktop application running on a modern multicore system, can make a big difference on a mobile platform.
In Java Today, Michael Heinrichs addresses JavaFX performance issues in JavaFX Mobile Applications - Best Practices for Improving Performance: "As everybody who is interested in JavaFX knows by now, JavaFX Mobile was released in February 2009. This article captures lessons we learned while preparing the release and provides some hints on how to improve the performance of JavaFX Mobile applications..."
The NetBeans team announced NetBeans IDE 6.7 Beta Available for Download!: "The NetBeans team is pleased to announce the availability of NetBeans IDE 6.7 Beta. Download NetBeans IDE 6.7 Beta; Learn More about 6.7 Beta. NetBeans 6.7 Beta introduces an exciting feature - integration with Project Kenai, a collaborative environment where developers can host their open-source projects. With NetBeans and Kenai, a team of developers can create projects, edit, debug, build, and commit code, and have discussions all through one easy-to-use interface..."
Meawhile, bytor provides an update on the latest WebSpace Server Developer Tools: "Apologies for neglecting the portal space, after the big release we've been heads down keeping up with demand. However, there are a lot of new happenings in the WebSpace! There have been several new items in the development space. Cheten has done a nicewriteupof support for Liferay Hooks Plugins in WebSpace's Portal Pack..."
In today's Weblogs, James Gosling reminds people about the ongoing JavaOne free pass and travel contest: "Can't afford a JavaOne pass or travel expenses? We're running a contest to help get you there."
Rama Pulavarthi announces that JAX-WS Maven 2 Plugin 1.12 released: "JAX-WS Maven2 plugin 1.12 is released which has some bug fixes related to configuring the wsimport/wsgen options and minor usability issue. JAX-WS maven plugin 1.12 depends on recently released JAX-WS RI 2.1.7. Along with other changes in JAX-WS RI 2.1.7, For maven users it has one important bug fix related to the dependency on the woodstox..."
And Rajiv Mordani posted Servlet 3.0 PFD draft coming soon: "It's been a while since my last update. However I am pleased to report that the Proposed Final Draft (PFD) of Servlet 3.0 is now been handed off to the JCP. Some highlights of what is in the PFD draft: The issues around Async have been worked out and Greg will also be posting an update to his last set of comments. Basically there were some tweaks to the APIs and semantics..."
Today is the last full day for voting in this week's java.net Poll. The poll asks "Which aspect of Java technology is the primary focus your current work efforts?"
This week's Spotlightis The Developer Insight Series, Part 2: Code Talk, in which Janice J. Heiss asks renowned developers about the keys to writing good code: "In Part Two, we hear code advice from five distinguished developers: Joshua Bloch and Masood Mortazavi echo Goetz's advice to keep code simple. Jaron Lanier and Victoria Livschitz want to radically change the way code is created. And renowned bug fixer Brian Harry provides tips on bug fixing while emphasizing what the process can teach us."
In the Forums,
rachit84 is wondering about a Delay in web service response: "Hi Folks, I've deployed two web services (say A and B) in Glassfish V2ur1. A receives around 60 hits a minute and B just 1 or 2. There is a constraint on the response time for B, which is to be less then 5 seconds. This is where the problem is. A request with a new parameter returns in about 11 seconds for the first time. The subsequent request with the same parameter takes only less than 2 seconds. In the server the request arrives within 1 second and the processing is completed in less then 1 second. However, the service monitor shows a response time of 10 to 11 seconds. I don't understand were the remaining 8 seconds is getting added. The web service is deployed as an EJB and is build on JAXWS 2.0... "
ab11 asks about Soap validation best practice?: "What is the "proper" way to handle validation of a XML for a glassfish/metro WS? My understanding is that validation is turned off by default, so glassfish will marshall the XML into java classes if possible, or to a null object if the XML did not validate. The obvious issue with this is the server can't tell if the object is null due to validation failure or due to a null being sent. Configuring validation to be on seems a bit painful is presumably non-standard (because it defaults to off?). any thoughts?"
enygma2002 asks Why is it said that Relay communication is HTTP only?: "Hi! This is not very clear. The jxta docs say that relays use HTTP to relay messages to firewalled/NATed peers. This implies that you need to use HTTP communication and that if you turn it off, you will not be able to use Relay peers. In practice though, I am using relay peers through TCP *only* (HTTP disabled) and it works great. I have also set the tcp port to 80 to make sure the peers use an opened outgoing port. It is also unclear why there is a separation between TCP (Network protocol) and HTTP (Application protocol, built on top of TCP). Logically, if you were to disable TCP, all your communication would also be disable. Instead, jxta treats them as if they were both network protocols and HTTP can run independently from TCP. This is confusing..."
Current and upcoming Java Events :
- April 27-30 - Eclipse Training Series Spring 2009
- May 1-3 - 2009 Greater Nebraska Software Symposium
- May 15-17 - 2009 Greater Atlanta Software Symposium: Spring Edition
- May 18-19 - GR8 Conference
- May 18-22 - Java Power Tools - Canberra Australia
- May 29-31 - 2009 Rocky Mountain Software Symposium: Spring Edition
- June 1-3 - CommunityOne West
- June 2-5 - JavaOne 2009
- June 22-25 - Jazoon'09
- June 26-28 - 2009 Research Triangle Software Symposium
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Continuing with yesterday's core topic of JavaFX, there's an interesting article about JavaFX mobile applications performance on the Sun Developer Network...