Internal JavaFX APIs

Some of the best JavaFX functionality can be found with the internal JavaFX APIs. Be warned that the internal JavaFX APIs are subject to change without warning and should not be relied upon as a result of this. As an additional warning the internal APIs do not go through the rigorous testing that the public ones do, so you're essentially on your own if anything goes pear shaped. Below are some interesting APIs (in JavaFX 1.3) that are worth keeping an eye on since they may influence what appears in the next JavaFX release, or any other future JavaFX releases.


PerformanceTracker

Recently some work has been done in developing a system to measure performance for a JavaFX application. I do not currently have a JavaFX application that can be used for trying out PerformanceTracker (located in com.sun.javafx.perf) thus I don't know if it works. At the moment PerformanceTracker is restricted to reporting FPS and basic performance logging so it is still in the early stages.

To start with PerformanceTracker it will need access to a Scene object, eg:

def perfTracker = PerformanceTracker.getSceneTracker(scene);


FXRobotFactory

One of the most interesting parts of the internal JavaFX APIs in that it may be an indication of some useful functionality which could appear in a future JavaFX release. Just like AWT's Robot class FXRobotFactory (located in com.sun.javafx.robot) handles UI automation which is very useful for automated UI testing. In fact FXRobotFactory's design is almost identical to Robot so if you have used Robot in the past you will be right at home. Just don't expect FXRobotFactory to be relying on Robot though since it is completely independent (built from the ground up).

After attempting to try out FXRobotFactory it doesn't seem to work with Decora, but it may work with Prism (haven't tried). To start with FXRobotFactory it will need access to a Scene object, eg:

def robot = FXRobotFactory.createRobot(scene);


DateTimeEngine

After giving DateTimeEngine (located in com.sun.javafx.runtime.date) a spin I have been very tempted to use it with some of my JavaFX applications. It works but with one hitch, a TimeZone object will need to be passed in in order for it to work properly. DateTimeEngine allows date/time to be manipulated/viewed just like with Java's Calendar but much simpler to use. Not much would be needed to incorporate this API into JavaFX's DateTime, which I suspect is DateTimeEngine in disguise.

Below is a very small example of using DateTimeEngine:

def dt = DateTimeEngine.getInstance(DateTime{}.instant, TimeZone.getDefault());

println("Current Date: {dt.getDayOfMonth()}/{dt.getMonth()}/{dt.getYear()}");
println("Current Time: {dt.getHours()}:{dt.getMinutes()}:{dt.getSeconds()}");


Clipboard

The biggest surprise is the internal development of this API. Who knew that there were plans to allow JavaFX applications to access/manipulate the clipboard. Since Clipboard (located in com.sun.javafx.scene.transfer) needs no basic introduction I will go on to say that it definitely works with copying/pasting text, and may work with other data types although I haven't tried Clipboard with an image for instance. However I have had the chance encounter to accidentally use it to paste a Java object in a JavaFX application, but it could not be done since the class files (NetBeans platform ones) could not be found.

Below is how you would use Clipboard to transfer a String (clipboard copy) to it, and access the first clipboard item (clipboard paste):

def clipboard = Clipboard.getSystemClipboard();

// Copy a String from stringContent variable into the clipboard.
clipboard.placeString(stringContent);
// Paste first clipboard item into the println function.
println("Clipboard Content: {clipboard.getContents()[0]}");


Conclusion

As you can see there are some interesting developments going on with the JavaFX APIs. Who knows what may appear in a future JavaFX release. Some of the internal APIs are already usable but be aware that they are not public, hence the internal API disclaimer in the first paragraph. With that said there may be a sudden flurry of feature requests in the JavaFX bug database, based on a particular internal JavaFX API that people wish to see in JavaFX publicly.

Open Source Management For JavaFX

Currently Oracle is faced with making a decision on whether or not to fully open source JavaFX. At the moment there is an unanimous voice made by the JavaFX community for the technology to be fully open sourced, via the petition started by Steve Chin. Below are some options for managing the open sourcing of JavaFX if Oracle made the decision to open source the technology (fully).

• Apache
• Oracle
• JCP (Java Community Process)
  
• Foundation

Remember that open sourcing JavaFX is a long term solution that needs to be properly managed in order to fully reap the benefits of doing so. I will be looking at the options as if Oracle have made the decision (hypothetically) that the community is after (requiring). Key factors that will influence which organisation open sources JavaFX is:

• Ease of innovation for JavaFX with incorporating new features and systems, and the speed of getting them through
• Participation of the entire JavaFX community vs commercial interests
• Development and support of JavaFX on the mobile side (with JavaFX Mobile)
• Licensing of JavaFX so it can be used everywhere front-end applications are needed
• Allowing contributions which can be previewed/incorporated in future open source JavaFX releases
• Promoting JavaFX so that more people are actively supporting/using it

Apache

Advantages

• Very experienced with open sourcing technologies
• Allow innovative features to be included reasonably quickly
• Has a good licence that is balanced between personal and commercial use
• Flexible with allowing outside contributions

Disadvantages

• Conflict of interest with Apache Pivot which makes the organisation unsuitable to handle JavaFX
• Apache have little interest in the mobile side since they are mainly focused towards web development
• Marketing of JavaFX will not be very strong

As long as Apache continue to support and develop Apache Pivot there will be a conflict of interest that will affect their handling of JavaFX. If Apache is to handle the open sourcing of JavaFX it must completely drop Pivot first. What is another major concern is the fact that Apache have not developed a real interest in the mobile side, which is one of the keys to growing JavaFX even further.


Oracle

Advantages

• Have a reasonable interest in the mobile side with the desire to expand further into this area
• Reasonable speed of getting innovating features and systems implemented in future JavaFX releases
• Can provide strong marketing and development support for JavaFX (including JavaFX mobile)

Disadvantages

• Little experience with open sourcing technologies
• Unreasonable and heavy handed licensing for JavaFX that may prevent it from being used on other devices (mobile side)
• Will be restrictive with allowing outside contributions

With the recent events surrounding Oracle suing Google over some possible patent infringements Oracle is not helping their reputation with the JavaFX community. If anything Oracle has made themselves completely unsuitable for managing the open sourcing of JavaFX, therefore it would be best for them to pass it on to a trustworthy organisation.


JCP

Advantages

• Flexible with handling licensing for technologies
• Reasonable experience with open sourcing technologies
• An independent organisation with no major conflicts of interest that would affect the handling of JavaFX

Disadvantages

• Known for limiting innovation (very slow speed for including innovations in a technology)
• Too much politics involved with companies (large sized) dictating what happens with a technology (not very community orientated)
• Does not handle marketing since it is left to the members to decide if they will do it for a technology or not

Lack of innovation is a real weakness of the organisation that will heavily hurt JavaFX if the JCP were to handle the technology. Also the politics that is involved in the organisation would completely leave the community out in the cold, which means that JavaFX would not receive the improvements it needs for its target markets and the JavaFX developers.


Foundation

Advantages

• Most independent of all the options
• Everyone can get involved with contributing to JavaFX
• JavaFX Mobile will receive the best development and support it needs since the foundation is only focused on JavaFX itself
• Lots of innovation occurring at a very fast pace for JavaFX
• Can provide open licensing that is balanced between commercial and personal use
• Decisions with developing JavaFX are made by the community (who can freely join as members), not by some large organisations
• Marketing will be effectively targeted to suit JavaFX since that is all the foundation is dealing with

Disadvantages

• Foundation will take a reasonable amount of time to be formed
• Unproven option that will need to earn the JavaFX communities trust

Clearly having a foundation setup would be the best option since it is completely independent, and it will only focus on JavaFX itself. However the organisation will take some time to be formed, and it will need to gain the trust of the JavaFX community if it is going to work effectively.