20 March 2010

Internal JavaFX Activity

Since many months have passed with the release of JavaFX 1.2, and some coverage on JavaFX 1.3 (SoMa) it is time to see what is currently happening with JavaFX. With this post I will mainly cover what is currently happening with SoMa.

Do note that any information in this post is subject to change and may not be entirely accurate. Also I have made the best educated guess possible considering what little information is released officially, and from the JavaFX Issues database despite many issues not being made publicly available. Some information has already been covered in some of my previous posts, and on other blogs.


Controls

Once again there are not much changes to see since much of this area has already been covered in some of my previous posts. To get the best picture listed below is the list of controls that will be included in SoMa (this is from a Devoxx presentation on JavaFX 1.3):



All the listed controls that have an appended asterisk are the new controls in SoMa. One may have noticed that the total number of built-in controls for JavaFX will double when SoMa is released. I have not taken into account the possibility that the unstable controls may triple the number when combined with the stable ones. The Separator control is a new addition to the SoMa controls line up.

What is currently unknown is what unstable controls will appear in SoMa. At present unstable controls could be placed in the com.javafx.preview.control package, which would make it easy to separate the unstable controls from the stable ones. This also means software developers can try out future controls sooner rather than waiting for the next JavaFX release. After all JavaFX's release policy is about regular releases with the chance for software developers to try out early access features, that help shape future releases involving the entire community.


API

Currently the biggest changes to the JavaFX API are with the upcoming TV support. One of the key API changes is the addition of TV keyboard and remote control support. CSS support will be widened to include additional CSS properties. Any class/mixin that is a Group will be able to automatically resize Resizable nodes to their preferred size during a layout pass. For performance metrics there is going to a PerformanceTracker API that can be used for both the Prism and Swing graphics rendering systems.

Other possible API changes are layout root functionality through unmanaged Parent nodes, use of third party native libraries with JavaFX Script, and a preview of drag n drop support.


General

If this is correct a beta version of SoMa has been released recently (as of 23rd Feb 2010) although it is not available publicly, and SoMa is in a feature freeze. Such news is good to hear considering the length of time it is taking to develop SoMa. Hopefully SoMa will not be released around the time of JavaOne in September, which shouldn't be the case provided there are no other major delays.

At the moment if things keeping chugging along at a reasonable pace with the development of SoMa (with the end in sight) there will be no need to think of this as another case of Duke Nukem Forever. Definition - an announced product that despite all reassurances that it is still alive and kicking ends up being cancelled in the end (takes forever to be released).

Prism appears to be a major inclusion in SoMa despite the impression that it wouldn't be included in time. Additional information has come to light about Prism with the fact that unlike Swing/Decora (the current rendering system) graphics rendering will be done through OpenGL for Desktop, and OpenGL ES for Mobile. Yet to be confirmed is if Prism will take advantage of the GPU for the graphics rendering instead of the CPU, and what Prism's relationship with Newt is.

With tooling it appears as though the JavaFX Authoring Tool will be available for Linux, and Prism will be utilised in the Authoring Tool. Currently there is a review going on with the redistribution of the JavaFX runtime. If the result of the review is favourable then this could mean standalone JavaFX applications can be done, as well as having the JavaFX runtime distributed with some of the major Linux distributions (eg Ubuntu).


Conclusion

Based on the current activity for JavaFX it is certainly moving forward. Nothing has been mentioned so far on what is happening with JavaFX Script and the mobile side of JavaFX. It is great to see that Prism is going to be included and that there will be a chance to try out preview controls early.

Now Oracle needs to reveal what is currently happening with JavaFX Mobile. This will become urgent since other major RIA players (Silverlight, Flash/Flex) have been making announcements about support for various mobile platforms. How is Oracle responding to this with JavaFX Mobile? What other mobile platforms (Android, Symbian, Blackberry) are going to be supported with JavaFX Mobile?

16 March 2010

Scripting In JavaFX Script

Scripting is all about direct/accessible programming that can be used to quickly create small to medium sized programs. When it comes to scripting it does not always mean a dynamic programming language has to be involved. Static languages like Scala can be treated as though they do provide programming in a scripting like way.

A static programming language could be used instead provided there is a program that can behave like an interpreter to handle the source files. Also the programming language must not impose any structural conditions (eg a class must be defined in the source file first) in order for a program to work. In the case of JavaFX Script one can include statements straight away in a fx file without having to define a class first, hence the script part of the name.

There is a class in the JavaFX API that can handle basic scripting in a limited way, which would act as a reasonable starting base for a basic JavaFX Script interpreter. The FXEvaluator class allows JavaFX Script source to be evaluated provided javafxc.jar is in the application's classpath. It should be noted however that the source is evaluated by FXEvaluator without any specified context. Therefore any state created created during the evaluation of the source cannot be used by other scripts.

Should JavaFX become fully open sourced, and have its own interpreter (to compliment the compiler) then it could have its own unique place with the major Linux distributions. Imagine JavaFX being bundled with future versions of Ubuntu for instance. JavaFX Script could secure its place in Linux by providing scripting for creating basic GUI applications since, the GUI support is built in, easy to create a GUI application with very few lines of code, and the programming language is very easy to pick up.

Currently no other scripting languages that are bundled with the major Linux distributions allow GUI applications to be easily created since they are designed to create console applications, hence the creation of GUI applications is an afterthought (done through extensions – eg libraries). Linux needs its own GUI scripting language, not one where GUI support is an afterthought. This could be a golden opportunity for JavaFX to significantly increase its rate of adoption, and have other people involved with improving the technology.

08 March 2010

JavaFX Composer Overview (Update)

Since the preview 2 release many changes have been made to JavaFX Composer. The majority of the changes are with the Data Source templates.


Changes Made

  • More properties exposed in the Properties window
  • Shapes, colours, effects are now available in the Palette window
  • HTTP Data Source now handles the HTTP Post method
  • JDBC Data Source now supports setting up CRUD instead of just reading from a DB table
  • When setting up animations one can now use an inherited state animation
  • Standard attribute names used for extracting data for each data source (in Data Source Customiser)
  • File Data Source now supports loading files from additional sources (local FS, resource from class path, storage using the Storage API)
  • Analyser added to identify design problems with a form

Improvements Needed

  • Remove irritating requirement to have an object selected first (in design pane) before having it moved, rotated, bring up an accompanying context menu etc
  • Display chart(s) in real time inside the design pane
  • When an event handler's name is renamed some refactoring needs to occur on every property that is affected by the change
  • Still there is no ability to add custom controls/nodes to the palette (absolutely essential)
  • Allow shapes to be visually resized/rotated/skewed inside the design pane
  • Display animations for affected objects inside the design pane (eg an animation preview like OO Impress)
  • Display all visual objects inside the design pane in real time based on their set properties
  • Provide facilities for easily creating custom controls (visual and non visual) in a visual way (eg wizards, templates in palette, design pane setup for designing a custom control)

In general the biggest improvement that needs to be made in the JavaFX Composer is to allow custom controls/nodes to be incorporated. Since JavaFX is designed to allow custom front ends to be developed why prevent people from using 3rd party content (eg controls, graphics)?

JavaFX composer doesn't stop custom graphics from being incorporated so why should custom controls be any different? After all JavaFX already has a standard system for developing custom controls (using MVC – Model/View/Controller), so it should be possible to use custom controls.

01 March 2010

JavaFX Mobile

Currently JavaFX Mobile is only available on Windows Mobile devices (ones that run Windows Mobile 6 or later). Although this was a reasonable start for JavaFX on the mobile side initially its biggest competitor (Flash) has made a bit of a head start. Flash is now being supported on a few major mobile platforms (Blackberry, Android, Windows Mobile). Mobile development is an area that JavaFX can excel in provided JavaFX is supported on a wide number of mobile platforms and devices.

What are Oracle's plans for JavaFX Mobile? What new capabilities are going to be added to JavaFX Mobile? No mention has been made by Oracle on when JavaFX Mobile tooling will be made available on Linux (eg emulators, libs). This is important if JavaFX is going to be supported on Android mobile devices. At JavaOne 2008 some JavaFX applications were demoed on an Android device.

So far nothing has been mentioned since on JavaFX support for Android. What is the current status on the JavaFX Mobile runtime for Android? If it is anything like the Java runtime for Windows Mobile (codenamed Captain America) it will eventually be released to the public, hopefully.

Oracle will need to announce significant plans for JavaFX Mobile that will keep its marketing on track, by making deals that will see JavaFX supported on more major mobile platforms. Without making JavaFX available on a wide range of devices Oracle is breaking JavaFX's marketing statement, “JavaFX enables developers and content creators to quickly develop interactive applications that can easily be deployed across the widest variety of client devices - from mobile devices to desktops, to next generation television devices”.

It may be necessary for Oracle to develop and support multiple JavaFX Mobile runtimes (in house) in order to accelerate the deployment of JavaFX on mobile devices. Oracle needs to put its actions, and money where its mouth is in order for JavaFX to excel in the mobile area.

21 February 2010

Open Sourcing JavaFX

At the moment JavaFX has been partially open sourced with the compiler and parts of the platform API. There are some key parts like the JavaFX runtime that haven't been open sourced yet. Oracle have not mentioned what their plans are for open sourcing JavaFX. Have the open source efforts with JavaFX grounded to a halt, or is there some change with the plans that Oracle have not announced yet? From what I have been able to discover so far there isn't enough of JavaFX being open sourced (with the open source distribution) to make it useful unless the official JavaFX distribution is used.

It is surprising to see that that there isn't more of the platform API being open sourced. Many parts of the API are not encumbered with patents/copyright, and other possible legal issues. Why is there not more of the platform API being open sourced already? To make matters worse the JavaFX runtime cannot be freely distributed with a JavaFX application (eg bundled in a zip file). If a developer wishes to bundle the runtime with the application because the client doesn't have access to the Internet, then they are forced to use an alternative technology.

Somehow it is extremely silly that a developer is forced to use an alternative technology because of a licensing issue with distribution of the runtime. As a result this means that JavaFX cannot be considered to be truly open sourced since the licensing is not technology neutral. Many people have complained bitterly about the runtime bundling issue (“Allow us to distribute the JavaFX runtime binary”), which comes as no surprise since it is currently 3rd in the JavaFX Feedback forum. Which begs the question what is Oracle's attitude towards open source? How are Oracle going to resolve the licensing issue with bundling the runtime?

If Oracle are serious about furthering the efforts to open source JavaFX then they should have discussions with Google for the following reasons:

  • Obtain experience from Google on using a non restrictive license that promotes the use of technology (in this case JavaFX)
  • Get JavaFX onto Android devices on the mobile side since this will allow JavaFX to be more easily adopted onto other mobile platforms
  • Gain insights into increasing the acceptance of JavaFX with the open source community and on major open source platforms in general (eg Linux, Android)

16 February 2010

JFX Blocks (GUI) 0.2 Released

JFX Blocks (GUI) 0.2 has been released on Kenai. This is the result of the challenge I had assigned to myself, which is to create 10 JavaFX controls (non-visual/visual) within a month. I can definitely say I have met the challenge. JFX Blocks (GUI) release contains the following controls (non-visual and visual):

  • Anchor
  • Navigator (Known as NavigatorBlock)
  • Split View
  • Button Bar
  • Image Button
  • Navigator Bar
  • Slide View
  • Status Bar
  • Ticker
  • Toolbar

Do note that this release like JFX Blocks (Core) has not been tested on the mobile side. Currently the look for each control has not yet been finalised since I am trying to work out how to provide a consistent look across both mobile and desktop, if possible. Hence the controls do not have a very polished look as they are very much a work in progress.

05 February 2010

Oracle's Intentions With JavaFX

After Oracle made announcements of their various strategies it is a good step in the right direction. Especially when they announced that they “will invest heavily in JavaFX”. However Oracle have not mentioned a single word on what they plan to do with JavaFX Script. Will some of Oracle's investment include further developing JavaFX Script?

Many people that have reviewed JavaFX have often cited JavaFX Script as one of the major strengths of the JavaFX platform. Currently Oracle have not revealed if they intend to further develop JavaFX Script, and if so what improvements will be made. If Oracle is serious about supporting JavaFX (especially in their own business) then when will they start migrating all of their Flash/Flex applications to JavaFX?

What hasn't been mentioned by Oracle is their roadmap for JavaFX. At the moment nothing concrete has been revealed about the long term plans for JavaFX so that the community knows exactly where it is heading. Hopefully under Oracle's watch they will do a good job of covering what is currently happening with JavaFX on a reasonably regular basis, which does not leave the community almost completely in the dark. Although it is understandable that Oracle have not delved too much into the details surely additional information could have been provided.

Although this may sound like a crazy idea Oracle should consider buying RIM. Not much momentum is expected with this although I could be proven wrong about it, we will have to wait and see. JavaFX needs a proper mobile hardware platform to show what it can really offer to businesses and mobile developers. If Oracle were to purchase RIM they would benefit by:

  • Having a missing part that will make the solution even more complete (can provide mobile hardware – via Blackberry smart phones), unification
  • Being able to provide an optimal JavaFX experience (for users) by being able to tweak the hardware to run JavaFX mobile applications very well
  • Accessing additional markets that RIM are currently involved in like government, business professionals, consumers
  • Being able to deliver unique mobile solutions that not only cover software but also the hardware
  • The increased adoption of JavaFX on mobile platforms with providing an official mobile hardware platform where JavaFX mobile applications work very well

Clearly from Oracle's strategy with JavaFX they know the technology very well, and are mostly heading in the right direction with it. However Oracle need to provide safe multi-threading (concurrent programming) capabilities for JavaFX Script, and bolster the JavaFX APIs with support for a wider range of UI technologies (eg touch screens, 3D graphics). On the official Customer Feedback And Ideas For JavaFX forum these are the top ten feedback/ideas (ordered by rank):

  1. Create more native components, like form items, grids and menus
  2. Quick application startup
  3. Allow us to distribute the JavaFX runtime binary
  4. More JavaFX Runtime Ports, Windows Mobile/CE, Symbian, BlackBerry, Ubuntu on ARM, Chrome OS, Maemo
  5. Thread-safe JavaFX
  6. 3D support
  7. Multi-touch capabilities
  8. A full featured editor for editing Animations, UI
  9. Table widget with sorting, scrolling etc
  10. HTML renderer