JavaPosse Episode 328: JavaFX The Sequel
03 November 2010 4 comments
Reading time:
5 minutes
Word count:
965
Hello
I was rather pleased that the JavaPosse released the RoundUp 2010 session that I chaired JavaFX The Sequel podcast episode 328. The Roundup is a yearly unconference session organised by Bruce Eckel and JavaPosse and takes place in February or March at Crested Butte, Colorado, USA. Roundup 2010 was particular interesting, because we had just over one year of JavaFX releases since the version 1.0 in late 2008.
At the time the podcast was recorded, in March 2010, JavaFX Script was still the chosen way that Sun/Oracle were positioning the next Java rich user technology, JavaFX. We were still looking forward to the full JavaFX 1.3 release and all developers were mucking around with the JavaFX 1.2.2 release. During the conference Tor Norbye, a Sun/Oracle employee back then, had access to the non-public JavaFX 1.3 release branch and he gave us valuable in to the up and coming new features in 1.3.
Here is a picture of me at the JavaPosse Round Up 2010 at the fabulous restaurant Django at the top of the mountain resort that is Crested Butte. The cost is the restaurant is exhorbitant: one of everything, with two deserts for about USD 270. Recognisable folk include Frederick Simon (JFrog) , Robert Cooper, etc
In the podcost, there were a number of salient points that I liked and still are valid:
- JavaFX could have had an active travelling adovocate (an evangelist) like James Ward does for Adobe Flex
- JavaFX Script really required the equivalent of Tour de Flex from its earliest inception
- Modularisation of the Java runtime platform and how much this is crucial for JavaFX deployment in the past, present and future. Breaking up the JRE means that deployment of JVM application could be cheaper, faster and smaller for distribution
- In my opinion Sun/Oracle marketing chose the wrang name, “JavaFX” was far too close to the Adobe “Flex”. This was also confusing for non-IT people in the financial market industry where the term FX means Foreign Exchange or the further abbrevation of FOREX
- The expense of providing tooling for the JavaFX Script eventually caused it’s eventual ejection from commercial Sun/Oracle development. The overall cost of investing in building a domain specific language was underestimated, especially if it was statically compiled and required interaction with Java APIs, IDEs and debuggers
- JavaFX Script was also a victim of the merger and acquisition between Oracle and Sun Microsystems (2009-2010)
- It was far too hard to get into the JavaFX Partner Program as an individual and therefore outsiders could not innovate with the JavaFX SDK team to provide better solutions
- The inability of Swing developers to embed a JavaFX Script application in their own existing Swing applications
Now that there is a new Roadmap for JavaFX 2.0 since the JavaOne 2010 conference, some items from the above are now mute.
- Since JavaFX 2.0 APIs are being rewritten into Java language, therefore Swing developers will be to get full access to the new scenegraph model from Java for the first time ever
- Because the API is now rewritten in Java, means the door is suddenly thrown open to the alternative JVM languages such as Scala, Groovy, Clojure, Fantom, Erjang and others. Java is now the Mother language for client UI on the JVM
- The expensive tooling issue for JavaFX Script has gone away from Sun/Oracle point of view. Developers will be able to use all their favourite Java IDEs, debuggers and testing frameworks and toolkits for Java.
- The elegance and the power of JavaFX Script will be sorely missed, even though it will continue with next open source project of Visagé. No one outside of Sun/Oracle can see how elegant JavaFX Script binding feature will be implemented in the Java API for JavaFX 2.0. (This new Java binding implementation will become a crucial cornerstone of the DSL, see below)
In order to solve the lack of uptake issue for JavaFX, I think we need more context outside JavaFX (2.0) to become a reality, namely:
- A core league of developers, outside of Sun/Oracle, must create Domain Specific Language implementations for the JavaFX 2.0 API in their favourite alternate JVM language of choice
- The PRISM rendering pipeline must be completed and released with the JDK release in version 6 and 7
- The brand new Java plugin that uses PRISM exclusively must also be completed on time. This is essential to show off the hardware accelerated 2D and 3D graphics applications, which run inside web browser runtime such as Firefox, Opera and Google Chrome
- PRISM requires improved 3D primitives support. It needs the basics: planes, polygons, pyramids, meshes, surfaces, spheres, dodecahedrons, toroids, etc and not just cubes that we saw in the JavaOne 2010 keynote demonstrations
- The web start JNLP should be enhanced to allow dynamics properties and capabilities added to the application in order allows system administrators to customise deployment
- Media must be supported, at least in the output mode, e.g. H.264 video, MP3 playback, positioning, seeking and scrubbing. (If the Sun/Oracle team could also rush-release the ability to record audio input then that would be a superb bonus. See the popular Android Market application the Talking Tomcat)
- JavaFX requires the mountain of runtime support that is OpenJDK 7 and Jigsaw and the ability reduce the payload for downloading, installing and running an JavaFX application from a remote web server
- Keep the status quo of releasing Windows, MacOS and Linux essential. Sun/Oracle originally heavily investing in Windows JavaFX releases, I think recent history has shown that Linux and MacOS runtimes are now crucially important. It may be actually true in 2011 that Oracle Corp must invest some of the stockpile of billions of USD that it has in bank accounts in keeping Write Once Run Everywhere alive.
There is lot of work still be done in 2011.
Peter Pilgrim. Out. 3 November 2010 😉
( Updated 5 November 2010 )