When the majority of a company’s software engineers and consultants are primarily occupied with meeting the needs of its clients, opportunities for brainstorming and investigating new technologies as a team can become scarce. One option is to have staff permanently assigned to research. The problem with this approach is that research staff don’t get to experience first-hand the kind of real-world challenges facing commercial organizations. Another approach is to specifically allocate part of the yearly calendar, during which developers who are normally assigned to client projects, can get together and discuss and try out some of the ideas, which they’ve been bottling up inside their digitally oriented minds.
This is precisely what the annual Canoo Code Camp is designed for, and in May 2007 a group of Canoo’s developers again retreated to the Swiss mountains, carrying on their laptops outlines of some mini-projects, which they hoped to complete over an intense 3-4 day period.
One of the results of those mini-projects was the “Music Pinboard” application. As we state at the “Music Pinboard” download site, this application had a single intention: To investigate Sun’s new GUI scripting language JavaFX Script. Whilst the application may look fairly polished from the outside (a side effect of specifically seeking to create a “cool” look and feel), we need to stress that the app is prototypical in nature and as such was not subject to the rigors of a regular development. We actually think it likely that the application contains some bugs (although we hope not many) and we know for a fact that the application’s design is suboptimal in a number of respects. Here are some examples:
- Music Pinboard’s footprint is around 5.4MB, which is undoubtedly excessive. Given that the core application (the JFX script, plus a handful of web-service abstractions) is around 100kb, where does the rest of this footprint come from? Primarily from three sources: (i) The JFX Runtime; (ii) The dedicated web-service APIs from Amazon, Flickr etc.; (iii) The JDIC browser component used to playback YouTube’s video. Add these up, and as long as you’re not using some additional compression technology, you end up with figure above.
- Not being able to move the MP window around the screen would obviously be an unacceptable deficiency in a production application, but could be added in seconds given JFX’s declarative constructs. We’ve since asked ourselves why didn’t we think of this at the time
- Although the user-response time is primarily dictated by the response times of the web-services (which, incidentally, vary significantly according to time of day/week), we could almost certainly improve the handling of these calls, as well as the rendering and caching of the corresponding results.
There are really two things to note about these points.
Firstly, some big improvements could certainly be made with little effort, and so it would be incorrect to assume these deficiencies are intrinsic to JFX. On the contrary, the ease with which these improvements could be made is to JFX’s credit.
Secondly, although from a technical perspective it is important to distinguish between deficiencies in the Java platform and deficiencies with JFX-alpha, whatever problems there are with Java that are not specifically addressed by JFX will, of course, be inherited by JFX (one could name having to download and install the JRE as an example).
Finally, these issues do nothing to diminish the success of the Music Pinboard mini-project, which provided us with insights that could not have been gleaned from reading about JFX alone, and which we will continue to share with the wider community.