Android Support With Visage

Visage has achieved what no other language has done (except Java) with supporting Android without the need for wrapper APIs/libraries and a separate runtime. Most languages that run on Android require the use of ASE (Android Scripting Environment). ASE provides very limited support for the Android APIs, and worse acts as a wrapper which greatly limits performance, and heavily restricts what languages have access to in terms of Android functionality.

Already there is excitement with Visage supporting Android directly like Java without the need for extra baggage. One downside is that the Visage compiler has to do two compiles, one from Visage source code to Java byte code, and the other from Java byte code to Dalvik byte code. This means that performance is not going to be adequate for advanced Android applications, but simple applications will run okay. In time performance will improve as further tweaks are made to the compiler until it gets to the point where there is only a single compile (from Visage source code to Dalvik byte code). When that time comes Visage will have performance comparable to Java.

Another downside is that Visage does not support Android APIs that make use of generics. In time the situation will be rectified since generics support in Visage is top priority. Hence it will be about a month or two before the support appears. As such it will not be possible to create advanced Android applications for the moment. Some genericised APIs will have alternatives that can be used until the support is present.

Guessing from how much of the Android APIs will be supported by Visage based on the total classes/interfaces/enums it comes to roughly 84%, which is surprisingly high considering much of the Android API is genericised. With the proper support the total supported Android APIs would come to about 95-98%. At a very high percentage this would make Visage a very attractive alternative to Java for Android development. With that level of support very little functionality would be unavailable when it comes to developing Android applications.

It remains to be seen what Visage language features can be utilised on Android. Not all features will be available but that will change as the Android support improves. Currently Visage for Android has not be made publicly available yet. Expect a public release within the next few weeks or so.

Next year will be the year that Visage makes its mark on Android development. Finally a viable programming language is emerging for Android development, which goes far beyond creating hello world type applications.

Visage Moving Forward

Much progress has been made since the announcement of a new programming language called Visage. A Google Code website has been set up, and already there is a reasonable number of members (working on the compiler, tooling, or both). Overall reception to Visage has been highly positive with no shortage of volunteers, which makes the Visage community tick. Visage has certainly made a splash in the Java Lobby headlines with being one of the most popular links (with different articles) for about 2 weeks now. Having the creator of JavaFX Script (Chris Oliver) on board is a big bonus, which will help to keep the quality of the language (including the compiler) high.

Already in a short space of time the first preview of the Visage compiler has been released. In this release default properties are introduced, and cascading properties may also be included as well. Annotation and generics support is planned for a future Visage version. Although the first preview doesn't provide much it is one of many important steps towards creating a programming language that will revolutionise front-end development, especially mobile development in making it more accessible to a wide range of software developers.

Currently development is under way on Visage for Android, which should mean there is a release sometime next month that people can try out. Steve Chin is hosting a workshop on developing Android applications using Visage during Devox 2010 on the 17th of November. Speaking of Visage and Android I haven't heard any response so far from my key contact in regard to the Visage proposal for Google. There are talks underway on developing Visage for iOS (iPhone and iPad).

On the tooling side a development team has already been assembled to develop the NB plugin for Visage, and is currently using the NB plugin for JavaFX Script as a base. With development underway on Visage for Android I will be attempting to have a partnership established between the Visage community (on the NB plugin side) and the NB Android plugin community.

Visage has already made a considerable impact, which I think will evolve into a key technology to watch out for in 2011. Certainly if you are looking for a programming language to develop front-end applications then Visage should be investigated next year. With Visage growing at a fast rate which major company will support Visage first?

Visage - A Refreshing Change

With Oracle making the disappointing move to drop support for JavaFX Script, and leaving its users in the cold with no migration plans something had to be done to rectify the situation. At JavaOne Steve Chin announced plans for a new programming language called Visage. Visage is to be heavily based on JavaFX Script, but is designed to be portable to a number of different platforms. Any GUI toolkit can be used with the new language.

Like JavaFX Script Visage is to be strongly typed and allow front-end applications to be created easily and productively. Also a number of programming paradigms will be incorporated for front-end application development (Procedural, Object Orientated, Functional). Unlike JavaFX Script Visage is vendor neutral and community controlled. However partnerships will be established with other vendors to enable Visage to be ported to different platforms.

Many people and businesses that have made a considerable investment in JavaFX Script think that any investment made will be lost. With the creation of Visage one of its main priorities at the moment is to preserve the investment made by people and companies by providing a transition path. Plans are currently under way with Visage to help JavaFX Script users make the transition to the language. A migration process with JavaFX Script is not only very difficult but is unnecessary since the area of developing front-end applications is not properly handled by major programming languages.

One of the first discussions to appear after the creation of the Visage project is porting plans for some of the major mobile platforms (eg Android). This is a great idea for getting Visage off to a head start. I intend to release a proposal to Google within the next few days on establishing a partnership with the Visage team to port Visage to the Android platform, and to have Google involved in the development of the Visage language if possible.

Visage represents a fresh change that challenges the status quo. Why is there no programming language specifically designed to handle the creation of front-end applications (except for JavaFX Script)? How is it that mobile development has been made unnecessarily difficult for newcomers? Visage is the way to make mobile development more accessible to potential software developers, and to people getting started in mobile development for the first time.

If someone is getting started in programming then they should be able to start in mobile development, if they choose to do so. Unfortunately the reality is that they must start in a different area of software development since there are no viable options, unless one decides to get started in mobile web development instead. However getting involved in mobile web development is completely different from mobile development, which is not an ideal situation for a newcomer that wishes to get started in mobile development.

Currently Visage is in the design stage so anyone can contribute various ideas that might be good to incorporate for the language. Unfortunately my own proposals for Visage, which are in a presentation (an odp file) cannot be attached to this blog post. Hopefully I can submit the presentation to the Visage website.

JavaFX 2 - The Good, Bad, And Ugly

Plenty of changes have been announced at JavaOne with JavaFX in relation to JavaFX 2.0. In general there are a number of good changes which generally offset the bad and ugly ones.


Good

• JavaFX APIs will be made accessible to any JVM language
• New controls (TableView, SplitView, TabView, MediaPlayer, WebBrowser, RichText)
• Prism will become the standard graphics rendering system (does hardware rendering)
• New consistent layout system
• Support for high definition media (audio and video)
• The entire JavaFX platform will be open sourced by the end of the year
• Multi-threading support
• Prism plugin (for the web browser)
• Texture paint (using images)
• Synchronised media and animation
• New WebView node for embedding HTML content in a JavaFX application
• New WebEngine (used in WebView) for parsing HTML content which produces an HTML DOM

What I most look forward to are the new controls and built in multi-threading which will really make a huge difference when developing a sophisticated front-end application. It is good to see Prism being used as the standard rendering system since it will provide significant performance benefits. Finally the full open sourcing of JavaFX is going ahead which means JavaFX will enter a “renaissance” era with innovate development by the community, greater adoption, and greater momentum. It will be fascinating to see the direction that JavaFX heads into, and its uses.


Bad

• No official language for developing front-end JavaFX applications
• JavaFX Script is no longer supported by Oracle (from JavaFX 2.0 onwards)

Although very disappointing to see Oracle drop support for JavaFX Script there is a silver lining. Since JavaFX Script is fully open sourced the JavaFX community can take over its development. Many people have been spreading misinformation about JavaFX Script being dead when it isn't. What needs to happen is for a team to be assembled in order to continue the programming language's development.

Without a doubt JavaFX Script's development will continue so people shouldn't be too hasty to switch to another language for handling the front-end with JavaFX. If anything the decoupling of JavaFX Script from the JavaFX platform will make it easier to use the language with other JVM languages. One good example of this might be using JavaFX Script for the front-end, and Scala for the back-end, just imagine the potential possibilities!


Ugly

• No clear direction for JavaFX Mobile
• Proposed alternate HTML graphics rendering system offers very little advantages in relation to the huge number of risks/downsides involved

What should be the biggest concern to the JavaFX community now is the fact that Oracle are not providing a clear direction for JavaFX Mobile. Contrary to what other people have said about JavaFX Mobile being dead that is not true. What has actually happened is Oracle have placed JavaFX Mobile for CDLC on hold. JavaFX Mobile is still going (in a different direction) but Oracle's inaction with it is very frustrating.

If Oracle is having a huge amount of trouble with working out what to do with JavaFX Mobile then they need to bring additional people on board who are experienced with mobile development. Also Oracle needs to commit on freely providing JavaFX Mobile runtimes for some of the major mobile platforms (eg Android, Blackberry, Symbian), which should have been done in the first place.

There is a bit of excitement with the HTML rendering system (alternative to Prism), which may be used for the mobile side. What many people will not realise is that the idea of being able to run JavaFX applications without a runtime, on any device supporting HTML is an idea that faces too many downsides and risks. Why would Oracle head down this path when Prism can handle mobile rendering (in 2D and 3D), consistent rendering across different devices, provide very good performance, and is already well in development?

It seems as though Oracle have rushed head long into developing an alternative rendering system with no sufficient justification, and an absent mind on the downsides and risks involved. To get an idea of the downsides and risks with the alternative rendering system that Oracle might be developing refer to the list below:

• Limited rendering performance that is dependent on the browser used
• No support for 3D rendering
• Possible delays added to getting future JavaFX releases out
• Inconsistent rendering since different browsers will be used by users
• Many features will not be available since the rendering has to be done in a browser which may not be upgradeable in a mobile device
• Huge technical difficulties involved with properly rendering JavaFX application in a browser without the need for a plugin/runtime
• If the rendering system fails to deliver then it could cause a crippling blow with getting people to use the JavaFX platform (a bad reputation – look at Applets as a good example)

Conclusion

JavaFX's future is looking very bright despite Oracle no longer supporting JavaFX Script. Next year will certainly prove to be a very exciting year for JavaFX considering the sheer number of big changes planned by Oracle. Right now the biggest concern is with Oracle not properly directing JavaFX Mobile. Even worse is the fact that Oracle are not very active in the mobile space when they need to be competitive, less talk and more action/commitment by Oracle!

JavaFX 1.2 Application Development Cookbook Review

I have been offered the opportunity by Packt Publishing to review the JavaFX 1.2 Application Development Cookbook. In this review the book will be reviewed by relevance, content, and presentation. Do note that the ebook version is being used as the basis for the review. You can find out more details about the book on the Packt Publishing website. Listed below are the chapters in the book:

• Chapter 1: Getting Started With JavaFX
• Chapter 2: Creating JavaFX Applications
• Chapter 3: Transformations, Animations, And Effects
• Chapter 4: Components And Skinning
• Chapter 5: JavaFX Media
• Chapter 6: Working With Data
• Chapter 7: Deployment And Integration
• Chapter 8: The JavaFX Production Suite

Relevance

Despite the book being released at a time when JavaFX 1.3 is around much of the book's content is still applicable to the current JavaFX release. Keep in mind that you will need to work out any differences between JavaFX 1.2 and 1.3 in relation to the code samples throughout the book. Also some of the code samples may not run at all in JavaFX 1.3.

Considering that the book is a technical cookbook I was expecting all of the recipes to be tailored towards technical tasks instead of getting started type tasks. There are some recipes in the book which turn it into more of a tutorial/getting started type of book. As a result the book loses a bit of focus on being a true cookbook, which means there are less recipes covering technical tasks that could have been included. A true technical cookbook should not include getting started type recipes.


Presentation

In the ebook version the book cover is aligned incorrectly and is not ideally suited to the book itself. All titles are pleasant to the eye, and every screenshot clearly shows the final result for each recipe. The formatting styles utilised in the book are consistent although the headings are a bit squashed in the ebook version (not enough white space used before and after each heading).

Good fonts are used for the text and headings which make them very easy to read. All the code samples could do with some basic colour syntax highlighting to make them even easier to read. At least the code is indented correctly and can be easily copied from the ebook to an IDE for developers to try out.


Content

A good title and basic description is provided at the beginning of the book. When it comes to content the book comprehensively covers most topics that you would expect it to cover. However it is surprising to see that there are no recipes covering the parsing of XML and JSON files, and back-end multi-threading for instance. Clearly the content of the book is geared towards beginner to advanced JavaFX developers.


Navigating the book was very easy and anyone can jump to a particular recipe provided they have the required knowledge (as outlined under the recipe's Getting Ready section). This is due to the well thought out structuring of the book. Very good explanations are given for the technical aspects that can be learned while reading the book. Especially in the excellent How it works... sections where it walks you through how something is done in a methodical manner.


Conclusion

Overall I would highly recommend this book for beginner to advanced JavaFX developers as a place to find out how to do specific tasks via the recipes in the book. Beginner developers would benefit from going through some of the basic recipes in order to become familiar with JavaFX, in addition to going through a getting started type book. Advanced developers would benefit from understanding how to do the more advanced recipes, which cover some of the advanced uses of JavaFX.

JavaFX Improvements

Plenty of improvements have occurred since JavaFX 1.3 was released. It is interesting to see where the majority of improvements have occurred as well as where we might see other ones in the future. I can only speculate at this point as to what improvements might appear in JavaFX 1.4 (Presidio). Here are some of the improvements that have occurred since JavaFX 1.3:

• Faster cold and warm startup of JavaFX applications
• Default splash screen for JavaFX applications which includes a built-in progress bar
• Custom splash screen support for JavaFX applications
• Basic custom node/control support in JavaFX Composer
• Easier debugging of JavaFX applications
• A new set of data orientated JavaFX controls in JavaFX Composer
• Fragment design support in JavaFX Composer
• New Grid template in JavaFX Composer
• New CSS reference
• Updated JavaFX API documentation

As for what the main theme might be for the next JavaFX release I am guessing that it will be on “going back to basics”. With the basics this would include expanding JavaFX Script to include additional basic types, basic low level graphics access at the pixel level, date/time APIs, additional controls, basic front/back end multi-threading system, basic 3D support, and an expanded event handling system. The majority of this would heavily rely on Prism being stabilised and becoming the standard JavaFX rendering system for the next release. Below is a list of what is currently being considered for inclusion in JavaFX 1.4:

• Stroke positioning
• Text Editor control
• Split View control
• Map data type for JavaFX Script?
• Open URL in web browser
• Flexible/common method to specify resources
• Theme support
• Table View control
• Basic built-in multi-threading system?
• Z depth sorting (buffering)
• Full 3D transforms for 2D objects
• Multi directional text
• Customisable dialogs (eg for Alert)
• Palette control (part of foundation for IDE type applications)
• Support for dialog boxes (create your own)
• Spinner control
• Fill and stroke transition
• Stage level events
• HTML support for text (HTML control?)
• Support for 3D bounds

Not surprisingly new controls are in the list, including some long awaited ones. However there doesn't appear to be any mention on 3D primitives (essential to proper 3D support), or on APIs for accessing graphics on a low level which is increasingly becoming a major issue. Considering how many improvements depend on Prism being stabilised and becoming the standard rendering system, there is a bit of urgency with getting Prism ready in time. According to Oracle's 90 day release policy for JavaFX a new release is due. What will be seen in the next JavaFX release?

JFX Blocks (GUI) 0.3 Released

JFX Blocks (GUI) 0.3 has been released on Kenai. Here is the list of changes for this release:

• Five new controls introduced (AutoComplete, MediaPlayerBar, MessagePanel, NavigationTrail, SearchBox)
• New ArrowPoint shape
• Navigator has been renamed to NavigatorBlock (now located in org.jfx_blocks.gui.block)
• Basic search functionality provided by SearchProviderBlock (located in org.jfx_blocks.gui.block), which will be moved into the next JFX Blocks (Core) release
• Removed Toolbar control since JavaFX (ver 1.3 onwards) now covers it as a preview control
• MediaPlayerBar control is only available in the desktop profile due the use of desktop only GUI multithreading (may change in future releases)

In order to deliver a MediaPlayerBar control that would work as intended the FX.deferAction function had to be used. The deferAction function is only available in the desktop profile so it created a bit of a problem. Either not deliver the control at all or make it only available on the desktop, I chose the latter. As a result it exposes the less than ideal situation with GUI multi-threading for JavaFX where options are limited, and even worse the only option works with desktop JavaFX applications provided Decora is used.

With Prism due to replace Decora (as the standard graphics rendering system) soon a completely new multi-threading system will need to be built for JavaFX. Otherwise there will be some show stopper situations that will prevent a JavaFX application from being developed/deployed. For instance having more than one change made to the GUI at the same time without freezing the application. If the JavaFX team needed a good reason to kick start the initiative sooner rather than later then here it is!

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.

Moving JavaFX Forward

Recently some blog posts have been made questioning JavaFX's success and adoption. When it comes to this the JavaFX community is mixed with some saying that JavaFX has had reasonable success and adoption, while others are the direct opposite. It is all too easy to say that JavaFX has had no major successes when you only need to look around the corner to see the successes. Part of this reason is that some companies, and individuals are not publicly announcing that they have been using JavaFX, and what applications are using the technology. Also some of the community are not making a significant effort to see what companies and applications are using JavaFX.

While I can list some of the major applications that are using JavaFX I will not list all of them since the list is a big one that would take too long to go through. Many of these applications I have found to be innovative in their chosen field, and have been designed by actual designers, not software developers. Here are some of the major applications that use JavaFX:

• ThoughtSlinger (Word Processor)
• Indaba Music Console (Music Editor)
• TwentyOne (CRM)
• Timeshot (Photo Editor)
• Pirimap (Emergency Response History)
• MetaMaps (Diagram Editor)
• Ubivent Virtual Event (Event Hosting)
• WidgetFX (Desktop Widgets)

Here is a list of the major companies that have adopted the use of JavaFX in some of their applications (note that this is not a comprehensive list, it would take too long):

• Thoughtslinger Corporation
• IndabaMusic
• Ubivent
• Lodgon
• Canoo
• Oracle
• Exadel
• SWOffice

When it comes to the mobile area JavaFX has made very little progress. Not enough to make a significant difference against the RIA competitors. JavaFX's potential is largely untapped in this area. JavaFX has the potential to dominate in this area provided it is given the proper resources, and outsiders can contribute to improving the technology so it can be number 1. Open sourcing JavaFX would allow it to gain a foothold, especially with developing runtimes for some of the major mobile platforms (including Android), and making them freely available (without cost) to hardware vendors and users.

Deployment currently is the Achilles heel for JavaFX. Since JavaFX's first release it has been plagued with problematic loading times, and poor loading feedback for people using applications that utilise JavaFX, this is mostly problematic on the desktop side. Although the deployment situation is gradually improving much more still needs to be done in order to reach an acceptable level. When it comes to a rock and a hard place JavaFX is placed in a difficult situation where it can either wait for Java modularity to arrive, or develop a completely independent desktop runtime that does not rely on having the JRE present.

One blogger has commented that a good looking JavaFX application is solely determined by the technology itself, and that there are no good looking applications in the wild. Since this person is a User Interface Designer I am somewhat surprised that they would make a comment based on technology and not the people involved in the design. It really shows how much that person doesn't know about making good looking applications, what a great disappointment.

A good looking application is determined by the skill, and a little talent of the designer. In some cases the software developer / engineer acts as the designer, which is a very common situation and some have the rare ability to pull this off well. I have found plenty of JavaFX applications that are good looking. However the look of an application is a very subjective topic that greatly differs between people.

Designers don't need to use a specialised design tool in order for graphics to be used in a RIA technology. JavaFX already has integration via plugins with some of the major graphics design tools (Inkscape and Photoshop). At the moment the JavaFX Authoring tool is under development, and although Oracle is running a bit on the late side with development it will be worth it when it is released, “good things take time”.

There are two videos that showcase just how innovative the tool really is. If it was out today it would provide a major advantage for using JavaFX against the other RIA competitors. Oracle really need to provide regular communication on how the Authoring tool is progressing, which is sorely lacking. I can understand why some of the community are a bit worried about this.

Although JavaFX is lacking in a wide range of quality controls with each release more and more controls are being added. Increasing the number of built-in controls is the best way to go, as opposed to having third party control providers. Built-in controls provide consistent quality that software developers can rely on. Remember that JavaFX unlike Swing is designed for creating consumer applications where custom controls may be created on the fly.

As such it is absolutely pointless to compare Swing and JavaFX, only contrasting can be done between them. Regardless of which front-end technology is used it will not be possible to satisfy every situation where it is used, hence third party controls are used or custom ones are created.

Plenty of major real world JavaFX applications have their own custom controls created entirely using JavaFX. Oracle should look at incorporating some of these controls in future JavaFX releases. Why do we need to look at Swing when there are plenty of JavaFX applications that provide the missing controls? We have lots of inspiration to look at in the JavaFX camp with the work that is done using JavaFX. Oracle should seize on this to further improve JavaFX!

With each release JavaFX has gone from strength to strength, and proven critics wrong time and time again. What JavaFX needs to do in order to improve is to continue making solid improvements, make deployment faster and easier, have mobile runtimes for some of the major mobile platforms, and provide provide low level graphics and media manipulation APIs.

Right now JavaFX is at a crossroads with its reasonable level of success and adoption. In order for JavaFX to move forward further it must be FULLY open sourced in order to reach greater success and adoption, and to gain a solid foothold in the mobile area.

JFX Blocks Plugin 0.2 For NB Released

JFX Blocks Plugin 0.2 for NetBeans has been released on Kenai. Here is the list of features for this plugin:

• Create Test Case for a JavaFX source file (found in file's popup menu)
  
• Create Model Validator for a JavaFX source file (found in file's popup menu)
• Wizards for creating custom Lookups, App Controllers, Blocks, and Test Runners (for running Unit Tests)

With the "Create Model Validator" option it only creates the basic class structure for a Model Validator. It is planned to have default validation for model fields generated in the custom Model Validator in the next plugin release. As for an option to run the Unit Tests through a Test Runner, this may also be in the plan for the next release.

Possible Areas For JavaFX

Now is the time for JavaFX to expand into other areas. Many of you will already have some ideas as to which areas JavaFX should head into next. Listed below are some some possible areas for JavaFX to head into next:


Android Support

By far this is one of the most requested ideas, JavaFX providing support for Android with a runtime. Android has become one of the fastest growing mobile platforms, which is quickly creating a potential opportunity for JavaFX to thrive on the mobile scene provided Oracle seize the opportunity. Google would certainly welcome the opportunity to support JavaFX as another viable option for Android development. The ball is clearly now in Oracle's court on this one.

If Oracle are really listening to the Java/JavaFX community then a JavaFX runtime for Android will be made publicly available on the official JavaFX website, to install onto Android devices. On the JavaFX website it appears as though a runtime may be available for Android. In the JavaFX FAQ the following section adds to the mystery, “2.5 Can JavaFX applications run on an Android handset?”. There is nothing to confirm or deny if there is a JavaFX runtime available for Android at this stage.

What I would also like to add which no one else seems to have discussed in the blog sphere is JavaFX providing access to some of the Android APIs. After all the JavaFX architecture (on the mobile side) has been designed to be completely platform independent, thus it should be possible for the JavaFX runtime to have access to major platforms other than Java.


Built-in Database APIs

Already I have covered this in a previous blog post but have mentioned this since it is an important area not to neglect. Most applications that are developed will have some access to a database in one form or another. With JavaFX it really needs built-in database APIs, not mere wrappers. Surely this would be a great opportunity for JavaFX to innovate in this space. If Oracle wishes to prove that it is firmly committed to JavaFX then this is a great opportunity to show it.


Full 3D Support

Currently JavaFX has partial support in this area. I firmly believe that the area of Graphics has always been a real strength with JavaFX. It would be common sense for JavaFX to have full 3D support. Again this is a possible area that JavaFX can innovate in, and with the arrival of Prism we may see this come to fruition in the next JavaFX release.


Basic Multi-threading Support

More and more cases are being covered where there is a great need for built-in multi-threading support. Especially on the front end side which is JavaFX's domain. Multi-threading support only needs to be basic since back-end processing in not really JavaFX's focus. A real focus on the front-end should be made here as opposed to the back-end.


Low Level Media Manipulation

Plenty of JavaFX applications do low level manipulation of media, but have to use the Java APIs. Some of these applications include Indaba Console, Blue Bill mobile, JPedalFX, MetaMaps, PiriMap, and TimeShot. Why not have JavaFX provide low level media manipulation APIs (with graphics, video, and audio)?

What this means is not only creating the media but changing it as well. This is an interesting area that has not been fully exploited by the other RIA platforms. If JavaFX really wants to stand out from the crowd in a useful way then this would be the area to target in order to get ahead.

JavaFX App Development Part 2

Next area to cover for JavaFX App Development series is developing the application using JavaFX (version 1.3). Development of the application using JavaFX had its ups and downs. One highlight is the ease at which one can customise the view of the ListView control, very easy and flexible. The biggest downside is the fact that JavaFX does not have any built in support for concurrency (multi-threading), although Java code can be used for back-end concurrency. However when it comes to front-end concurrency there is only a single function in JavaFX which only works in a single situation (deferring the action to be executed at a later time).

JavaFX's single option for front-end concurrency is far from ideal. What happens if you're using Prism instead of Decora for displaying the application? If you're in that situation then you're out of luck! Such an issue being highlighted will likely increase the haste to include basic built-in concurrency for the front and back end stuff in JavaFX. Maybe this support will be in the next major release?

Customising/setting up controls is fairly straight forward with JavaFX. What makes this task especially easy is that fact that the look and feel can be completely decoupled with the CSS support. I have largely been satisfied with the suitability of the Caspian look. Still some tweaking of the look for the XTableView control will need to be done in order to make the text of selected rows readable. Some controls lack functionality that would make the application more complete. For example the Menu and MenuItem controls (preview) do not support keyboard accelerators (shortcuts), this is a known issue.

The tab ordering system used by JavaFX has been absolutely spot on, hence no manual intervention was needed, just layout nodes/controls correctly. What is missing is the ability to create custom dialogs. Currently too much unnecessary work is being done in Cookery to make a Stage behave like a custom dialog with mixed results, ugh! One suggestion for the JavaFX team is to provide a public-init instance variable called dialog in the Stage class, which sets the Stage to behave like a dialog when set to true (default value is set to false).

In terms of application performance it runs reasonably quickly, although some long term testing will need to be done to see how the application copes with long term use (under some stress). Hopefully I will not encounter the dreaded OutOfMemoryError with binding like I did with the original development of Cookery using JavaFX 1.2.

Listed below are the issues I encountered with JavaFX, and some third party libraries:


Using custom list cells in a ListView causes it to be improperly displayed

With the custom ListCell display empty string(s) if the current item is null.


No standalone JavaFX runtime to distribute with the application

Possible workaround is to connect the application via JNLP to the Internet, provided the target PC has Internet access.


Stage does not have a function for requesting focus

Hide the Stage first, then make it visible in order for it to gain the focus (works on some OS's).


JavaFX does not have any basic support for concurrency

Delegate the concurrency to code written in Java. Only a workaround if you need just back-end concurrency done.


JavaFX does not have a table control (eg TableView)

Use XTableView control from JFXtras library.


JavaFX does not have a built in database API

Use Java's JDBC API and/or JavaFX Composer's Data Source library. Only a workaround for a desktop JavaFX application.


The text for the selected rows is not readable for XTableView

Customise the look of XTableView using its skin property (use an instance of XTableSkin class). Note that doing it in CSS doesn't work at the moment.


JavaFX does not support creating a custom dialog box

Use XDialog class from JFXtras library. Only a workaround if you don't mind creating a front-end application with an in-cohesive look and feel.


Conclusion

With Cookery at the beta stage there will still be some long term testing to do. Some issues occur long after an application is completed, so it pays to get the user to use it for a while before it is finished. That way you can avoid some major bugs from popping up unexpectedly by catching them before they appear in the finished product.

Despite the fact that I had run into a few issues with using JavaFX I was still able to continue with development on Cookery, without any major show stoppers. This concludes the JavaFX App Development series.

JavaFX App Development Part 1

Currently I am developing a JavaFX application for handling cooking recipes called Cookery. Part 1 will cover my development experiences using the JavaFX Composer in NB 6.9 RC1. Previously I had written Cookery entirely using the NB code editor and JavaFX 1.2. Unfortunately I had encountered some show stopper performance issues (with data binding) during testing, which meant I could not make any further progress with the application. This time around Cookery is undergoing a complete rewrite from scratch using JavaFX 1.3.

Since I had developed Cookery previously I had some rough screen designs on paper. Using the Composer I was able to design screens that were close to what I had on paper. Unfortunately the Composer does not yet support custom controls/classes/nodes, which meant containers had to be used during layout to hold the custom controls, thus no accurate visual feedback. On the plus side I was able to setup the layout for each screen quickly and easily.

The Composer organises control properties in a sensible way that is easily accessible. I like that fact that all commonly used properties for the selected control is presented in the top area of the Properties window. Not all properties are available in the Properties window, of particular mention is the read only properties which do not appear at all. Strangely enough there is still to way to visually manipulate the properties for the Stage (eg set the title), and properties are not sorted in ascending order for each category.

If you have ever used the previous version of the Composer you will no doubt have run into some major performance issues. Luckily with the current version it is much more responsive, and opens up design files much quicker. Also whenever a small change is made to a design file and you rerun the JavaFX project it is much quicker to build, this helped to boost productivity when the project was being built many times.

A major downside with using the Composer is the fact that it does not honour the user's formatting settings when it generates code. This slowed development down unnecessarily while I had to fix up the formatting. One major issue that is of major concern is the excessive amount of scanning that occurs whenever a change is made to a design file. This verges close to being a performance show stopper. Hopefully this issue is becoming priority number 1 with the Composer team, and will be fixed by the time the final version of NB 6.9 arrives. If necessary NB 6.9 should be delayed by about a week. It appears that the scanning issue is very common in other areas (eg JavaFX, PHP, Java).

On the positive side using the menu bar customiser proved to be a highly productive experience. Initially when I first used it I though it would not be as productive to use as Matisse's one (NB's Swing GUI builder). Who wants to manually type out the menu structure? However it proved to be the direct opposite, even saving me from manually renaming/positioning all menus/menu items. Also each menu can be customised individually without having to create the menu from scratch.

Another positive with using the Composer is that is generates very readable code that happens to be in a coding style that is very similar to my own. Any generated event handlers and binding functions/variables can be manually repositioned/changed on the fly. For handling data/state there is the Composer library which came in handy since I needed a general JavaFX database library for the application. There were two issues with the library which I was able to fix since all the source files are automatically created (for the first time only) in the project's src directory.

Listed below are the issues I encountered with the Composer and its library (most issues have workarounds):


Getting a value from a Record returns null

Ensure that the column name is correct and is in the correct case (eg in upper case).


Composer does not allow a custom control to be used visually in the Design Pane

Use a place holder Container (eg Group) in the control's place, and manually add the control to the Container.


Cannot directly resize Container's in the Design Pane

No workaround.


Cannot set any of the properties for the Stage (eg the title) in the Properties window

No workaround.


JDBC Data Source customiser does not handle a custom connection string

Change the connection property in the Properties window for the data source.


Sometimes the design file cannot be manually saved when a change is made

Close the design file and select the Save option when the dialog appears.


Excessive scrolling needs to be done with a design file in Design mode

No workaround.


Refactoring breaks when done in a design file (in Source mode)

Do manual refactoring without the assistance of the code editor's refactoring functions.


JavaFX Script code generated the Composer does not honour the user's formatting settings

Manually format the generated code.


DbDataSource returns a null RecordSet via getRecordSet function

Ensure all DbDataSource properties are correct. Also you may need to invoke the fetchData function before getting the RecordSet.


RecordSet returns null when using get(colName) function on a table column of type CLOB

Manually add code in the fetchData function (in DbDataSource) for retrieving CLOBs.


DbDataSource does not return the last insert ID used

Manually add code in DbDataSource to get the last insert id. Only a workaround if the chosen DB has a function that returns the last insert ID.


RecordSet does not have a specific function for retrieving a xxx type value from a column

Use the get function instead to retrieve the value and cast it to the specific type

JFX Blocks (Core) 0.4 Released

JFX Blocks (Core) 0.4 has been released on Kenai. Here is the list of the major changes for this release:

• New Unit Testing system
• New Expect, and UnitTest classes (in org.jfx_blocks.core) for the new Unit Testing system
• New Month class (in org.jfx_blocks.core) covers months for dates
• Replaced classes that are only found in JSE (Java Standard Edition) with ones that are in the JavaFX Common profile, or in JSE/JME (Java Mobile Edition)
• New ObjectRegistryBlock mixin (in org.jfx_blocks.core.block) which handles retrieving objects from a single place
• LookupBlock mixin now supports using an object registry (see the point above) with the added objRegistry property
• Added date/time functions to Utility class
• Renamed resourceIdRegistry, and internalResourceIdRegistry properties in LookupBlock mixin to storageRegistry and jarRegistry
• New DateValidator and TimeValidator classes (in org.jfx_blocks.core.validator)

Since the previous testing system that I used from JFXtras does not work on the mobile side, and the fact that it has not been updated fully to use JavaFX 1.3 (currently in beta) has lead to the creation of a new testing system. As a result the new system can be used for mobile and TV applications, not just the desktop ones since the system does not use reflection or JSE specific classes/functions.

Although I have tried to ensure that the core part of JFX Blocks can be used with mobile and TV applications there may be some JSE specific functions used. Should that be the case then there is still some work to do in order to make JFX Blocks (Core) mobile and TV compatible.

First Impressions Of Ubuntu 10.04

With the arrival of Ubuntu 10.04 LTS this is the most important Ubuntu release in years. LTS releases only come once every 2 years so a release like this can either make or break Ubuntu's reputation amongst users. I have decided to do a fresh install of Ubuntu in order to eliminate all problems that result from doing an upgrade, and to properly assess the Ubuntu experience.

For existing Ubuntu users the first thing you will notice when booting off the Ubuntu CD is that the live environment is started straight away. The existing CD menu is now hidden which means you will have to press a key before the CD loads into the live environment. There should be a text message that is displayed informing users that they can show additional options for the CD before it loads.

Once the live environment is loaded I found that the installer wouldn't startup (saw an error message). However when I manually started up the installer it worked fine. No major changes were made to the installer compared to previous versions of Ubuntu. Installation of the OS was quick and easy. With the first startup of Ubuntu 10.04 an error message appeared (on a black screen) which isn't a good look. Although it was not a critical error it shouldn't have been displayed at all. Canonical have had ample time to fix the issue since Ubuntu 8.04.

Last time I had done a fresh install of Ubuntu I had to battle with getting the display setup properly, which meant manually creating a configuration file, and playing Russian roulette with obtaining a working display. No user should ever have to endure this, luckily with 10.04 the display was properly setup which meant no more display headaches. Also for the first time with Ubuntu the highest resolution was selected which is a big plus, and there was no need to edit/create a configuration file. An additional bonus was the fact that desktop effects worked properly for the first time after I had installed the Nvidia driver.

Setting up wireless networking and the printer was a breeze, which meant I could start printing some documents straight away. As for sound there are still some serious performance issues which should have been addressed after the release of Ubuntu 9.10. The last Ubuntu LTS release (8.04) didn't have these issues at all despite using the Pulse Audio system for sound. Canonical will need to address the sound basics urgently if it wishes to get musicians/sound professionals on board.

Performance has been greatly improved with very quick startup and shutdown times. On the downside with my PC I experienced slow logins which appeared to be frozen for a moment even though they weren't. A new look 'n feel has been used which makes it easier to see what windows/applications are selected, easier to read text, and more visually appealing. However the window buttons have been moved to left hand side which is a very bad design decision considering existing users, which are used to seeing the buttons on the right.

For some reason the keyboard shortcuts are no longer displayed which is another very bad design decision. Once again Canonical are not considering their existing users. Remember it is much cheaper to retain existing users rather than attract new ones. As for applications Gimp has been replaced with Open Office Draw and a basic video editor has been added (called Pitivi). What is missing now is a basic backup application.

The Ubuntu Software Centre has been enhanced with the ability to see software provided by Ubuntu, or from Canonical's partners. Some software categories now have sub categories and installation of software is more accessible. Social networking features have been integrated into Ubuntu which is a first for an OS. Although social networking is not of particular interest to me other users will greatly benefit from have social networking done in a single place.

Overall Canonical have done a reasonably good job with the current Ubuntu release but clearly have a bit of work to do with sound and login performance, startup presentation, and the look 'n feel. It is quite clear that this a benchmark Ubuntu release which will really attract new users, however existing users are being left a bit neglected by Canonical.

JavaFX Support In Eclipse

Exadel are developing the JavaFX plugin for Eclipse which covers JavaFX 1.2 but not 1.3. Previously Sun were developing the plugin which covered JavaFX 1.2, however they had limited resources at the time which meant the community had to pitch in. For this post I will be covering version 1.2.4 of the Exadel JavaFX plugin.

Installation of the plugin proved to be very difficult due to navigating a confusing website in order to obtain the right one. The first one I had downloaded refused to install in Eclipse (no proper explanation given), it wasn't until I had used the other version that I finally had a successful install. An additional concern is that the installation/uninstallation of the plugin is very slow. After the installation no default JavaFX SDK had been picked up which is a bit of a minor annoyance.

With the JavaFX preferences there are some options for source code formatting and the editor. At the moment it is not possible to debug a JavaFX project due to the missing toggle breakpoint feature. No automatic formatting option is available for JavaFX source files. Code completion is extremely limited at the moment. Only JavaFX keywords and script level variables/constants/functions (defined by the developer) will be picked up in the editor. Move and rename refactorings do not work properly for classes and packages. Strangely there is no delete refactoring option available.

Full syntax highlighting is provided. Errors in a JavaFX source file will only be picked up once the file is saved. This can really slow you down which highlights the need for real time error checking as you type. Plenty of JavaFX snippets are available for use in a JavaFX source file. Even better is the fact that you can easily add your own. When you create a new JavaFX source file you have the option to generate some JavaFX Script from some templates (CustomNode, Stage, Shapes, Scene), which is a nice touch when you need something created quickly (eg a panel for a screen).

Overall Exadel have much work to do in order to bring the plugin up to scratch on the basics. Proper code completion is needed as well as breakpoint support for debugging. Also installation of the JavaFX plugin needs to be easier and much quicker to install/uninstall. If possible Exadel needs to implement real time error checking for JavaFX source files.

Update: Exadel have released version 1.3 of the plugin which supports JavaFX 1.3. For an easy way to install/update the JavaFX plugin add the stable plugin site in Available Software Sites (inside the Preferences window).

JavaFX 1.3 Tooling

Many people are bound to cover what is new with JavaFX 1.3. Instead of covering the same thing I will cover the tooling for JavaFX 1.3. NB 6.9 Beta and JavaFX Composer for NB 6.9 Beta will be covered in this blog post. Currently in terms of cross platform tooling for JavaFX there is Inkscape (for creating images in FXD/FXZ format), NB (main JavaFX IDE), and JavaFX Composer (JavaFX GUI Builder in NB). As for the JavaFX Authoring tool it is currently in Alpha, though it will soon be at the Beta stage.

Most of the changes for the NB JavaFX editor is with hints and formatting. Previously the only hints available were restricted to “Implement Abstract Functions” and “Fix Imports”. However hints have been extended to include “Add Class XX” and “Add Function XX”. It is strange to see no options for setting up hints for JavaFX despite additional hints becoming available. You can now see all tasks for JavaFX in the Tasks window (eg TODOs). Additional items are available in the Palette, which cover some of the new items in JavaFX 1.3 (including the controls). Of note is the quicker build performance when doing a build/run of a JavaFX project.

Formatting of JavaFX Script code still requires a bit of work before NB 6.9 is released. For instance I found that the formatting of string literals would cause a huge number of blank lines to be inserted. Although it does not prevent a compile it is a huge nuisance that shouldn't be there in the first place. Another issue with formatting is the fact that braces for object literals are placed on a new line half indented, even though I have set the braces to just be on a new line. Additional formatting options are now available in the Options window for JavaFX.

In terms of the biggest changes most of them are found in JavaFX Composer. Once again the build performance is quicker. One can really notice the difference after making a simple change such as readjusting the size of a control on a Scene. The palette now includes the new items in JavaFX 1.3 (especially the new controls). With the Properties window there is a convenient button which allows one to quickly toggle the display of a category via a popup menu. This is very handy when you are not using a wide screen display. There is now concrete specifications for the JavaFX Composer QL (Query Language), which is used for filtering data sources.

JavaFX Composer is much more responsive compared to the previous version in NB 6.8, and properly outlines the contents of a design file (inside the Navigator window) in Design mode after exiting Source mode. Certain controls now have a corresponding customize button in the Properties window to customise them like one of the Composer templates. All data sources now have a “Raw Data” tab so you can see any data before it is filtered. In the design pane guidelines now appear when placing a control inside a Container (layout). Unfortunately there is still no support for handling custom JavaFX controls/nodes. Hopefully this will be remedied in a maintenance release.

With so many new changes in JavaFX Composer I have only covered some of the significant ones. All other changes can be found on the NB Wiki. Additional new features to note with NB which apply are basic refactoring options for CSS files, quick access to make simple changes to an Ant build (via double yellow arrow button), and build server support (with Hudson).

As you can see Oracle have certainly not stood still with the JavaFX tooling. Further adding to this is the fact that they are collaborating closer with Inkscape in realising that this vector graphics tool is commonly being used amongst JavaFX developers. One can hope that Oracle will establish closer ties with other open source tool vendors in the future. Tooling for JavaFX is certainly in a much better state than it was over 6 months ago.

Use Of JavaFX Script

JavaFX Script is currently being used in interesting places and is enjoying increased uptake. One indication of this is the TIOBE Index which provides a rough indication of programming language trends. It is a great place to visit to see what programming languages should be looked at. Currently JavaFX Script is at position 22 on the index. I would expect JavaFX Script to reach the top 20 next month which is a realistic view provided the growth considerably increases from its present rate.

Among the most interesting uses of JavaFX Script is as a DSL for JSF, which is currently being developed by Exadel. Although it is in the early stages some people may see it as viable option when its first version is completed. Some people find using a markup language to be highly inflexible and cumbersome when creating a front end application, so there is room for JavaFX Script to handle that area.

Recently there was an article published on Java Lobby on using JavaFX Script to develop a basic NetBeans platform application. Personally I see this as a major area when JavaFX Script can enjoy a good rate of adoption provided there is a good level of support. It isn't a surprise to see this happening since there is a considerable interest in using JavaFX Script as an alternative to Java for creating NB platform applications. One can expect this to further increase as time goes on.

Oracle should take note that JavaFX Script requires a significant level of development in order to stay relevant. Dropping support for the language would be a huge mistake that would greatly set back JavaFX. Oracle may not fully realise the potential that JavaFX Script has with being able to unify front end development across different hardware platforms (desktop, mobile, TV). Why cease development of a technology that is starting to see a reasonable amount of adoption?

If you are using JavaFX Script in an interesting way then please let me know through the comments. What needs to be known are the major use cases for JavaFX Script, which will make it easier to improve it for its target markets.

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?

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.

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.

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.

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)
  

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.

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