Software Development Journey

Visage Development/Support Survey

2011-06-04T17:36:00.000-07:00

I have created a survey on improving the development and support for the Visage language. If you can help out with completing the survey that would be highly appreciated. The more results that can be collected from the survey the more complete the picture will be on improving Visage. Please get as many people as you can involved with completing the survey.

Loading...

Visage Roadmap

2011-01-14T15:18:00.000-08:00

Based on what information I could gather from the discussions, Visage Issue DB, blog posts a clear enough picture has emerged on which to create a roadmap for Visage. Do note that the roadmap below is subject to change, some guesses have been made, and may not be entirely accurate.

Visage 1.0 (Beta 1) – 20 February?

Android 2 (eg 2.1, 2.2, and 2.3) and JavaFX 1 (eg 1.3) support
Default properties
Angle data type
Length data type (covering screen metrics, and metric measuring system)
Colour data type

Visage 1.0 (Beta 2) – 20 April?

Required properties
General built-in locale system for strings (locale lookup via fxproperties files)
Cascading properties
Map data type
Updated Android 2 library

Visage 1.0 (Stable) – 20 June?

Annotations support
Generics support
JavaFX 2 support
Basic tooling for Visage (eg programmer's text editor)

Post Visage 1.0

Basic built-in lookup system using cascading properties?
RTS (Reusable Type System)
Declarative functions
Add a more open license (BSD type one)
Application controller?

JavaFX 2 support will likely be delayed as much as possible to allow time to properly support the platform. Hopefully JavaFX 2 will be ready in time for its beta release. Some of the mentioned points may appear in earlier or later Visage releases. Main themes for Visage 1.0 is support for multiple development platforms (currently Android and JavaFX), enhanced property support, stronger platform API support, and additional data types.

Other Languages For Web Platform

2011-01-02T14:31:00.000-08:00

When one thinks of a development platform one would expect that multiple languages would be able to access the platform APIs. With the web platform this isn't the case. Only JavaScript is supported across most web browsers which means it is the only official language for the web platform. Any other language that wants to access the browser/web APIs must go through JavaScript which isn't an acceptable situation. Increasingly more and more languages are going down the compile to JavaScript route. Hence it provides a clear indication that developers want to develop front end web applications in a language other than JavaScript.

Considering how JavaScript has no real competition since there are no other languages embedded in the web browsers it is time that this changed. I am surprised that the current situation of JavaScript only for web development has gone on for this long. Why are no other major browser makers incorporating other languages? For a start a browser maker like Google or Mozilla could incorporate a language like Visage for instance.

It comes as no surprise that JavaScript has undergone very little change due to the lack of competition (think no languages). When some of the details for JavaScript 2 were released there were few big changes made to the language. Imagine if JavaScript had actual competition, think of how much more improved JavaScript would be with the next major version.

The best way to incorporate other languages in a browser would be to have something similar to byte code running in a virtual machine (VM). As such any language that wants to access the browser/web API would need to be compiled first, unless there is an alternative way. Using a VM instead of embedding each language would help to keep the download size of each browser to a minimum. Naturally compile time would be the main bottleneck unless it is kept to a minimum. Now this would be a worthwhile challenge for Google (a fast performing browser VM)!

By incorporating a VM instead of embedding languages in a browser any language would be able to run in the browser (provided it runs in the VM), without requiring a separate runtime to be installed. For the future of web development this would be the next big evolution (not referring to Web 3.0) moving forward. If this is to work then the same system needs to be used by every major browser maker.

What browser makers will take up the challenge of incorporating other languages by implementing a cross platform virtual machine? Even though the challenge is great all it takes is for one browser maker to get the ball rolling.

Android Support With Visage

2010-12-15T12:09:00.000-08:00

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

2010-10-20T13:26:00.000-07:00

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

2010-09-30T23:21:00.000-07:00

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

2010-09-23T14:13:00.000-07:00

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

2010-09-18T19:59:00.000-07:00

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

2010-09-15T02:52:00.000-07:00

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

2010-09-01T03:57:00.000-07:00

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

2010-08-26T04:05:00.000-07:00

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

2010-08-15T14:10:00.000-07:00

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

2010-07-25T16:12:00.000-07:00

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:

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):

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

2010-06-28T17:24:00.000-07:00

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

2010-06-27T04:23:00.000-07:00

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

2010-06-14T14:20:00.000-07:00

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

2010-06-06T00:24:00.000-07:00

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

2010-05-24T13:18:00.000-07:00

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

2010-05-10T17:41:00.000-07:00

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

2010-05-02T18:38:00.000-07:00

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

2010-04-25T16:18:00.000-07:00

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

2010-04-12T12:33:00.000-07:00

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

2010-03-19T13:02:00.000-07:00

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

2010-03-15T12:52:00.000-07:00

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)

2010-03-07T11:44:00.000-08:00

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

2010-02-28T11:38:00.000-08:00

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

2010-02-20T14:29:00.000-08:00

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

2010-02-15T10:40:00.000-08:00

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

2010-02-04T11:56:00.000-08:00

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):

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

Three Good JavaFX Applications

2010-01-28T14:59:00.000-08:00

Listed below are 3 good JavaFX applications that use JavaFX in interesting ways, which are worth mentioning. I have chosen these 3 applications because they put JavaFX to good use, and are likely to be used reasonably regularly (eg on a daily basis).

Indaba Console

First major example of a major application that has transitioned from Flash/Flex to JavaFX. It is used by musicians to create music tracks that are stored in the cloud (the Internet). Not many users would create music but it is still an application worth covering.

When starting the application it is reasonably quick to appear and has reasonable performance. Upon looking at the application for the first time it has a good unique look that targets its audience. One may note that there are a few custom controls that may appear in a future JavaFX release (not the same ones though).

With Indaba Console a user can:

Create and edit tracks
Easily drag n drop pre made audio clips onto existing tracks
Save a track as a wav or aiff file to the desktop
Apply sound effects
Play a track

Thought Slinger

A word processor that stands apart from other word processors by offering secure (encrypted) storage of documents in the cloud, and comprehensive collaboration features (eg instant messaging and documents reviews). Upon looking at the application one may think that a Swing control has been used to act as the text editor. Surprisingly though via a second look it is just a custom JavaFX control.

Again there are some controls that may appear in a future JavaFX release (not the same ones though). My suggestion to the JavaFX team is to have a chat with the developers of Thought Slinger on how they created the custom text editor, a very impressive custom control!

With Thought Slinger a user can:

Freeze parts of a document that cannot be edited by other users
Apply a password to the document
Allow editing access to the document for certain users
Communicate with other users editing the same document via instant messaging
Adjust font, size and other styling for parts of a document
Redo and undo changes made to a document
Save the document as an HTML, odt, txt or docx file
Print the document
Track all changes made to the document (by the owner of the document and other users)

Cheqlist

Very handy application for keeping track of tasks in a list. As an original application it does not use any Swing controls (all controls are done in JavaFX). It is another example of an application that stores data in the cloud. All data appears to be accessed/stored through a Remember The Milk REST API.

With Cheqlist a user can:

Create, edit and remove lists
Create, edit and remove tasks
Easily search through tasks by list or keyword(s)
Adjust the look of the application to suit

Conclusion

From what has been covered by this post JavaFX allows one to quickly create good looking, but practical applications that can easily interact with the Internet. Do note that the time taken to develop an application will greatly vary depending on what is being developed. The developers of the two applications covered (Idaba Console, and Thought Slinger) should be interviewed as it would give a good insight into why JavaFX was chosen, and the issues/benefits of developing an application using JavaFX.

JFX Blocks (Core) 0.3 Released

2010-01-18T01:54:00.000-08:00

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

Added logging facility
Moved UtilityBlock (renamed Utility) to /org/jfx_blocks/core
Provided a model and type validator system
Additional functionality has been added to Utility (was UtilityBlock)
Added an output buffer which is similar to Java's StringBuffer class

Currently the first sample has not yet been updated for the current JFX Blocks (Core) release. A new version of the sample will be released soon.

JavaFX Competition Proposal

2010-01-04T17:09:00.000-08:00

With the beginning of the new year now is a good time to look at a new JavaFX competition. What I am proposing for the competition (on the official JavaFX website) is one for the best JavaFX control, which can be used in any JavaFX application. Here are the following conditions for the proposed competition:

Any submitted control must be a native JavaFX control (not a native Swing control)
The control cannot be a reimplementation of an existing JavaFX 1.2 control
Skin(s) must be available for the control and the control has to be skinnable via CSS
Only a visual control can be submitted

A competition like this would certainly help with boosting the number of available controls for JavaFX (supplied by Sun and the community). Also it would go a long way towards making JavaFX a more viable technology for building RIA applications (both consumer and enterprise). If you have any further ideas for the proposed competition let me know in the blog comments.

JavaFX Composer Overview

2009-12-19T20:02:00.000-08:00

With the release of JavaFX Composer (the JavaFX GUI builder for NetBeans) I decided to go through a general overview of the tool. With the overview it will answer some key questions which include identifying any missing areas not covered by the tool, point out any of the tool's strengths, point out any of the tool's weaknesses, and look at the major differences between Masisse (the Swing GUI builder for NetBeans) and JavaFX Composer.

Key Questions

Before the release of JavaFX Composer there were some key questions compiled about the tool that needed answers. These questions are:

Can data binding be done visually?
Does JavaFX Composer handle creating/editing animations visually?
Are GUI changes reflected in real time as they occur?
Is the .fxc file format also used in the JavaFX Authoring tool (for exchanging view data)?
Can custom JavaFX controls be added to the palette via drag 'n' drop or through a wizard?
Does JavaFX Composer support visual binding of data to/from a DB?
What differences are there between JavaFX Composer and the JavaFX Authoring tool?
What are “states” in JavaFX Composer?
What advantages will JavaFX Composer have over Matisse?
What is the relationship between JavaFX Composer and JavaFX Designer?

Differences With JavaFX Composer Compared To Matisse

Separates the view from the controller and model
Supports a number of data sources for data binding beyond just DB and general objects
Supports the ability to do animation visually
Does not support doing dynamic layout visually
All generated code is clean and easy to understand
Handles layout for multiple screen sizes
Supports the idea of “states” with GUI design for GUI navigation
Can toggle the display of one or more groups (categories) of properties
Uses a separate XML type file for storing the GUI design data (not the view)
Does not allow JavaFX classes, JavaFX controls (custom ones), and JavaFX classes that extend CustomNode to be added to the palette

Advantages

Can do animations visually for any JavaFX control
Uses “state” based design
Generates clean code that is easy to understand and can be customised
Template system greatly simplifies building forms by having all options in one place and templates can be easily customised after they are created

What To Improve

Need additional extensibility for JavaFX Composer with the ability to add new JavaFX controls, custom nodes and classes to the palette window
Have a standard system for developing custom templates that can be added to the palette window
All public properties for controls and JavaFX classes should be exposed in the properties window
Real time display of controls that have continuous animations which are started immediately
Provide official documentation for JavaFX Composer that covers all built in features
Provide writing capability to all data sources that are supported by JavaFX Composer
Use the fx source files (which contain the view) instead of the fxc files if two way editing is supported (use a single file instead of two)

Conclusion

Currently the biggest issue with JavaFX Composer is the fact that extensibility is too limited. For example a custom JavaFX control is created and a JavaFX developer wishes to use it with the tool for building a JavaFX application, by adding it to the palette window. Data binding in general is restricted to reading for some data sources (JDBC, File System, File, HTTP). With the next release of the tool one would expect that there will be the ability to write to all data sources.

Templates are a great productivity booster in JavaFX Composer since all options for creating and customising them is under one place. This is unlike wizards where one has to rerun the wizard if anything has to be changed, and not all options are covered by the wizard itself. Also each template produces code that can be easily customised when needed.

At the moment there is an awkward situation where if one edits an fxc file the corresponding fx file is not updated. Also this occurs (in the opposite direction) if one edits the fx file instead. With an fxc file it is more difficult to edit and harder to read compared to an fx file. Why have two different file types present for a JavaFX application's view? It is highly recommended that the fx file is solely used if two way editing is supported in a future release.

JFX Blocks (Core) 0.2 Released

2009-12-15T15:08:00.000-08:00

On the 15th of December (NZDT) JFX Blocks (Core) 0.2 was released on Kenai. This release covers the following:

General utilities
Application specific utilities and the basic part of the application lifecycle
Basic IO facilities (reading from an InputStream and writing to an OutputStream)
Lookups of resources in Storage and in the application's JAR (has a basic lookup system)
Type converter for handling conversions between reference and primitive types (especially handy when using parts of the Java API that expect and/or return a primitive type)

Do note that this release has not been tested on the mobile side since there is no JavaFX mobile emulator for Linux at the moment. Temporarily provided with the release is a mixin for creating test cases (for Unit Testing) which will be removed with a later release of JFX Blocks (Core). As for samples there is a single one that will be released on Kenai soon. In many ways the JFX Blocks release pushes the boundaries of what JavaFX is capable of, and even exposes some areas that need to be addressed (e.g. the need for a Map data type).

Feel free to provided feedback since this is an experimental release that is exploring how to best provide a library to meet the needs of JavaFX developers. It has only just scratched the surface with meeting some of these needs. In particular the core part of the library is trying to address common functionality that a JavaFX developer needs in a new or existing JavaFX application.

Current Status On JavaFX 1.3

2009-11-23T00:13:00.000-08:00

Some news has been reported from the Devoxx 09 conference including what is currently happening with JavaFX. A lot of people who have been to the conference have reported that there will be a JavaFX GUI designer for NetBeans. It has been reported that the GUI designer will be part of the upcoming NetBeans 6.8 which is due to be released on the 10th of December (approx), unless there are any major delays. What is currently unknown about the GUI designer is whether or not it supports JavaFX 1.2, we will soon see if it does.

Some people at the conference have also reported that some of the new JavaFX 1.3 controls were demonstrated using the GUI designer for NetBeans. The major question is will JavaFX 1.3 come with NetBeans 6.8? Currently there is no official word on exactly what new controls will be included in JavaFX 1.3. What is an important question though is will the GUI designer handle the visual design of animations? Also how does the GUI designer differ from the JavaFX Authoring tool?

Prism may actually be the new JavaFX runtime starting with JavaFX 1.3? This is certainly confusing as I originally thought that prism was only a rendering system, all will be revealed when JavaFX 1.3 is released. One person who reported on the Prism demonstration at Devoxx mentioned that it is lightning fast performance wise. It will be interesting to see how that performance scales when there are many nodes on the scenegraph and/or a lot of binding is involved.

Unfortunately there is no official word on when the JavaFX mobile emulators will be released for Linux, although there is the old screenshot that shows the JME (Java Mobile Edition) 3 SDK in action on Linux. Hopefully the mobile emulators will be arriving soon. As always there is nothing official being released about the exact release date for JavaFX 1.3 (it will be released as soon as its ready – good things take time :<) ).

Oracle wise (not the actual company) I think that JavaFX 1.3 will most likely be released around the middle of December after the release of NetBeans 6.8. Again I am just repeating what I have mentioned in a previous post. It will be most interesting to see exactly when JavaFX 1.3 is released. Apparently JavaFX 1.3 will be targeted for release around Jan/Feb 2010 (Jonathan Giles mentioned this in a Twitter) which is a long time away. Prism will most likely not appear in JavaFX 1.3, but will be demonstrated at JavaOne 2010. A possible reason for this might be that Prism will be handling full 3D in the next release of JavaFX after SoMa.

Introducing JFX Blocks

2009-11-15T13:27:00.000-08:00

Introduction

Often there will be parts (blocks – see further down for an explanation) that you want to add to an existing or new application. These parts are missing items of functionality which make the application complete. Today's issues often revolve around being able to quickly and easily find parts that adequately satisfy the functionality that is missing without adding bloat.

But when some parts are found you often find yourself in the situation where other parts have to be used, and/or some prior configuration (significant amounts) is required before using it. Frameworks are extremely poor when it comes to supplying what you need since there is additional baggage that has to be handled as mentioned above.

How does one grab what they need without requiring anything else? A key answer to this is with platform libraries since they do not require you to use what you don't need. Instead the libraries underlying design (eg through loose coupling) permits software developers to use only what they need, and not what they don't want.

An inspiration of this is the NetBeans Platform because the designers have taken into consideration that every application is different in terms of its requirements, and have designed the platform as such that if anything else is required it has sufficient design reasons for including it (eg makes it easier to implement a given piece of functionality).

Another issue is being able to easily integrate a part into an existing application. Especially if this application is used by the masses. Difficulties arise when significant changes need to be made in order to incorporate the part. In this situation you would go for a different part (from a different supplier - see further down for an explanation) provided there are some choices out there.

Certainly we are starting to see the emergence of platform libraries as a trend away from frameworks. So you could be mistaken for thinking that libraries are back with a vengeance. Indeed that is exactly what is occurring since software developers are after a balance between flexibility and simplicity when building applications.

JFX Blocks is designed to quickly and easily build new JavaFX applications (mobile and desktop, not mobile web), and add functionality to existing JavaFX applications. Currently JFX Blocks is at the design stage therefore any core functionality that is mentioned may change.

Main Aims

Emphasise a declarative approach to building applications with a focus on what is needed
Use mixins as “building blocks” to easily build against other existing code
Minimise or remove the need for configuration before using a “block”
Provide default behaviour for every “block” so it is usable straight “out of the box” in a new or existing application
Emphasise the use of design to provide “blocks” that produce huge benefits with little effort
Maintain high documentation standards that incorporate an extensive use of examples (samples) for getting started
Minimise the use of tight coupling
Maintain high coding standards
Provide core functionality that will work on both mobile (not mobile web) and desktop applications without any major changes (JFX Blocks common profile)

Terminology

Block – A self contained piece of functionality that is loosely coupled (a mixin)
Container – Contains a set of blocks that handle a specific (unique) area (a JAR)
Blueprint – Like a block except it contains no default behaviour and it only specifies how to structure something (a mixin that is like a interface)
Connector – Enables a block to be “connected” to an application (a class)
Supplier – Designs and creates the blocks/containers/blueprints/connectors
Builder – The user that builds or partly builds an application using what is provided by supplier(s)

Core Functionality

A basic (generic) lookup system that can obtain physical files, JAR resources
IO (Input/Output) utilities
Factory for controlled creation of “blocks”
Handle all aspects of the application's lifecycle (eg startup, shutdown, resource loading, setting up user settings)
A basic (generic) persistence system for general data, program and user settings

First Impressions Of Ubuntu 9.10

2009-11-08T14:22:00.000-08:00

Lately you might have noticed that I haven't made a post for quite some time. The reason for the delay is because of some mysterious display problems with the previous version of Ubuntu (8.04 LTS) that I used. Eventually the problems reached a point where the OS had to be reinstalled, and it was a great opportunity to make a clean install of Ubuntu 9.10. After all with the glowing reviews of the OS hitting the web I thought that it would be reasonably smooth sailing with getting the current version of Ubuntu installed.

Display Woes

Smooth sailing wasn't to be the case with the live CD failing to display anything at all. In order to get something displayed the resolution was changed through the use of two keyboard shortcuts (Ctrl+Alt++, Ctrl+Alt+-). Normally most people (non technical) would give up at this point so Ubuntu was not making a good impression so far. At that point the installer could then be started.

Luckily the install went very smoothly and after a reboot everything seemed to be going fine until.... more problems occurred. Once EnvyNG (video driver management for ATI and NVidia video cards) was installed I had tried to run it but to no avail. It turns out that one has to install the envyng-qt package since envyng-gtk is broken. After a reboot the display was showing the CLI login prompt which was flickering for some strange reason.

When I tried entering in the username no characters were being displayed at all. This happened to be one of the most irritating parts of installing and setting up Ubuntu since many people (who have an ATI or NVidia video card) were having the exact same issue, and it took a long time to resolve (a matter of hours). Even worse was the fact that the Nvidia driver package is currently broken thus there is no GUI login being displayed.

Once the NVidia drivers were installed using the version supplied on the official NVidia website some progress was finally being made. Not all the display issues had been resolved yet since not all of the resolutions were being picked up properly. This part took the longest amount of time to resolve through trial and error with editing /etc/X11/xorg.conf. In my case I had eventually reached the point where I had to put up with the resolutions that the NVidia driver had picked up. Luckily after commenting out the "HorizSync" and "VertRefresh" lines in the monitor section, and logging in again all of the resolutions were then picked up properly.

What Is New And Different

Many packages in the Ubuntu repositories have been updated including NetBeans, and the Sun JRE (Java runtime)
Firefox is now at version 3.5.4
Open Office is now at version 3.1.1
Gnome is now at version 2.28.1
Vastly improved general performance (start up times are so quick that they rival the Hibernate mode)
The new Palimpsest Disk Utility 2.28.0 has been included, more details to follow
Introduction of the new Ubuntu One service, more details to follow
Default option to use the new ext4 file system when partitioning
Linux kernel is now at version 2.6.31-14

What is most notable about the current Ubuntu release is the introduction of the brand new Ubuntu One service. Ubuntu One allows contacts, notes, and files (2GB free storage) to be synchronised with one or more Ubuntu (9.10 or later) PCs. Initially when I logged into the service (via Firefox) a message was displayed saying there was a version mismatch with the server. An OS update quickly resolved the problem with updating the Ubuntu One desktop client to handle the current server.

I would advise anyone who is using Ubuntu One on Ubuntu to use Nautilus (file browser) when uploading a batch of files, since the web client is slow and produces errors every time a file is uploaded. With the desktop client you can add directories and files to the Ubuntu One directory. For example with the joe user this is located in "/home/joe/Ubuntu One". Every time you add or remove a directory and/or file the client automatically synchronises the changes whenever your computer is connected with the service.

Another notable change in Ubuntu is the new Palimpsest Disk Utility. Palimpest manages disk partitions, and provides very handy diagnostic information on partitions and all storage devices. It is absolutely amazing what you can find out using this handy utility. For example one can find out about the current airflow temperature for a particular storage device, and can see what the normal temperature is supposed to be. Also Palimpest automatically notifies the OS if there are any major problems, and can perform some tests on the user's behalf for a particular storage device.

One other major change is the brand new refreshing Ubuntu look. This look reminds me of the JavaFX look, classy, legible, and visually appealing which doesn't take up too much screen real estate (netbook friendly).

Lastly Ubuntu's Add Software has been replaced with the new Ubuntu Software Center. When using the software center you can no longer install/uninstall a group of software at once, and more details are provided for each piece of software (including a screenshot, package name and version etc). Installation and uninstallation of software is now handled in the same window used to browse software, and one can swap between "Get Free Software" and "Installed Software" tabs with navigation being remembered with "Get Free Software".

Current Issues

Sound performance in my case is much worse than in Ubuntu 8.04. There is a very noticeable sound lag (consistent) which wasn't present before. Hopefully this will be resolved in the next batch of OS updates. Wireless networking is now a bit of hit or miss. It used to be in Ubuntu 8.04 that if the IP address was not picked up through DHCP the first time, then the second attempt would always pick up an address. However with Ubuntu 9.10 I usually have to restart the wireless router in order for an IP address to be obtained properly. Again the next batch of OS updates should resolve this.

Conclusion

For people who have an ATI or NVidia video card in their machine, and are currently thinking of installing Ubuntu 9.10 are advised to hold off until Ubuntu 10.04 LTS arrives. The reason for this is because 10.04 is a long term support release which is supposed to be much more robust for hardware support, and OS stability. If your machine contains an Intel video card then 9.10 is for you since many improvements have been made with supporting Intel video cards out of the box.

Why Oracle Should Dump JDeveloper For NetBeans (Update)

2009-11-01T14:55:00.000-08:00

This is going to be a very short post. Oracle have announced in their Sun Product Support FAQ that they are endorsing NetBeans as an open source IDE option for the Java platform alongside Eclipse and JDeveloper. Some people have commented that Oracle have given a lukewarm response to NetBeans.

What is not certain is how Oracle are going to support NetBeans. Perhaps Oracle will be releasing plugins for NetBeans just like they are currently doing for Eclipse? This is probably a mere coincidence but NetBeans is moving to a completely new infrastructure (an announcement was made just a few days after the Oracle FAQ was released), I am sure that this has nothing to do with the timing of Oracle's FAQ.

On an unrelated side note the next version of NetBeans (version 6.8), which is going to be released around December will have JavaFX support ready straight away. Also all future NetBeans releases are going to be synchronised with the JavaFX releases (current and future) which should help increase development speed, and improve stability for the JavaFX plugin.

Why Oracle Should Dump JDeveloper For NetBeans

2009-10-23T17:18:00.000-07:00

Lately there has been a bit of speculation about what will happen to NetBeans once Oracle has acquired Sun. Personally I am one of the people who is supporting the case for Oracle to support NetBeans, and to drop support for JDeveloper. It seems to me after reading what software developers think of the idea of Oracle supporting NetBeans is that the majority of them are in favor of Oracle supporting NetBeans, and dumping support for JDeveloper. Also many software developers expressed the wish for Oracle to take the best of JDeveloper (namely the DB support) and incorporate it into NetBeans itself.

When considering whether or not to support JDeveloper or NetBeans the following needs to be taken into consideration:

Quality of support for development of JavaFX applications
The ability of the IDE to support the big picture (supporting things that will make a difference in the long run for software developers)
Support of widely used software development techniques (eg Agile development, Test Driven Design (TDD), team collaboration)
Level of support for Polygot programming
General IDE platform support
Support for different types of software development (mobile, web, desktop, TV)
User uptake of the IDE and IDE platform

JDeveloper Advantages

Very good support for enterprise software development (for web development)
Comprehensive support for software diagramming
Reasonable built in diagnostic tools
Ready to use out of the box for web development
Very good support for developing DB based applications
Good performance

JDeveloper Disadvantages

No support for mobile and TV development
Poor support for desktop development
No support for Polygot programming
Does not support JavaFX development
Very limited uptake of IDE and IDE platform
IDE platform is mainly used in some major Oracle products

NetBeans Advantages

Reasonable support for enterprise software development (for web development)
Very good support for desktop, mobile and TV development
Reasonably good support for JavaFX development (currently #1 IDE) *1
Very good support for Polygot programming (currently supports JavaFX Script, Java, Ruby, PHP, Groovy, C/C++)
IDE and IDE platform are very widely used (high uptake among businesses and software developers)
Very good diagnostic tools (including profiler and debugger)
Excellent usability and out of the box experience
Reasonably good performance

NetBeans Disadvantages

Limited support for developing DB based applications
Limited support for software diagramming

Some major questions remain on the very existance of JDeveloper.

Why did Oracle create JDeveloper when they could have used Eclipse or NetBeans instead?
Why is JDeveloper designed to be similar to NetBeans (eg with the user interface)?
Why does JDeveloper have such poor adoption rates compared to NetBeans?
Why is Oracle taking such an interest in the NetBeans IDE platform when it directly competes with JDeveloper's IDE platform?

For the first time the development of the JavaFX NetBeans plugin has been syncronised with the general development of the NetBeans IDE. It is expected that when NetBeans 6.8 is released that a JavaFX bundle will be available at the same time (on the official downloads web page). Such a change will further bolster the commitment NetBeans has to supporting JavaFX development, and will bring about stronger support in the future. Since Oracle is going to support JavaFX (in a big way) they will find themselves in an very difficult situation should they not support NetBeans (*1).

With the current situation of NetBeans not lagging far behind Eclipse (*2), and the fact that JDeveloper is not one of the top three IDEs is there really room for a 4th IDE (apart from NetBeans, Eclipse, IntelliJ Idea)? Is Oracle willing to get offside with software developers by not supporting NetBeans?

There is a potential risk that if Oracle does not support NetBeans then there could be a mass migration of developers from the Java platform to the .NET platform. Some reasons for this are:

a) NetBeans is more similar to Visual Studio than Eclipse. Why would NetBeans users go to Eclipse when Visual Studio is more familiar? Already there are many Java developers that are doing some software development part time on .NET. Many software developers consider having to use Eclipse (for development on the Java platform) a major step backward from a quality perspective.

b) Possible perception by some software developers that Oracle is not acting in the best interests of the Java platform by removing a major choice, that helps move the platform forward. One can see some of this in the NetBeans Users mailing list, it could be the tip of the iceberg.

*1 - As indicated in an informal poll conducted by Jo Conner
*2 - As indicated in an informal poll by Jo Conner and in a recent poll on java.net

Should There Be A DB API For JavaFX?

2009-10-14T11:38:00.000-07:00

I have identified a possible gaping hole when it comes to developing mobile JavaFX applications. Currently there is no DB API that can be used for accessing a database on a CLDC (mobile Java) mobile device. With the mobile part of JavaFX currently targeting mid to high range devices (mobile phones and smart phone) it would make sense to have a database on the devices. After all these devices would have enough resources to run a simple database (one with reduced features and capabilities, compared to its desktop version).

So it is time to start the debate on a DB API for JavaFX. Lets say hypothetically a DB API was to be designed for JavaFX. This DB API would have the following design considerations:

Provide a consistent API that can provide basic features across all hardware platforms (desktop, mobile, TV)
Allows advanced DB features to be accessed by desktop JavaFX applications only
Minimises its footprint and provides as many features as possible, without using too many resources on mobile devices
Allows seamless conversion between JavaFX Script and DB data types
Provides reasonably good performance (including on mobile devices)
Can easily allow syncronisation of data between the JavaFX application and the database in very few steps
Provides the cabability of querying the DB for internal information without requiring the JavaFX developer to describe the DB structure beforehand

Database API Advantages

Can use a database with a CLDC profile device (mobile JavaFX uses CLDC as the base)
Can easily use all JavaFX Script and JavaFX features (eg binding, triggers, functional programming)
Provides an opportunity for JavaFX to gain a major advantage over its RIA rivals
Can take advantage of Oracle's excellent DB design expertise (when the acquisition of Sun goes through)
A single DB API that can be used across all hardware platforms (desktop, mobile, TV)
Able to populate JavaFX controls (both visual and non visual) quickly and easily with very few steps
Seamless conversion between DB and JavaFX Script data types
Reasonably good performance with JavaFX having direct access to the DB

Database API Disadvantages

Will require JavaFX developers to learn a completely new API
Generics and reflection will not be available to incorporate into the design of the DB API
DB API will require existing DBs to supply new drivers
A new DB may need to be created from the ground up to work accross all hardware platforms (incl with CLDC profile devices)
May require existing DBs to adjust their design/implementation in order to be compatible with the DB API
Very challenging to design and implement an effective DB API (may take at least a year before it is ready for production use?)

Now the "should there be a DB API for JavaFX" could very well become one of the biggest JavaFX debates of the year. Currently the DB API for JavaFX should not be considered a high priority at the moment, since JavaFX is mainly aimed at creating graphical applications. Therefore stuff like 3D support is a much higher priority for inclusion in JavaFX.

I intend to make it very clear that I am not a member of the Sun JavaFX team. What I have mentioned above is my own opinions and in no way reflects the opinions of the Sun JavaFX team.

What Next For JavaFX? (Update)

2009-10-06T14:38:00.001-07:00

After looking through the bug system for JavaFX the majority of changes/additions for the next release are with the controls. Do note that the details on what controls are available may change. Here is the list of controls that will either, be in SoMa (+), not in SoMa (-), highly likely to be in SoMa (*), or may be in SoMa (^).

Grid Layout (+)
Spacer (+)
Separator (+)
Menu (+)
Menu Button (+)
Custom List Cell (*)
Search Box (*)
Password Box (+)
Text Area (+)
Table (+)
Spinner (+)
Dialog (^)
Multi Style Text Area (*)
Popup (+)
Tooltip (^)
Status Bar (*)
Tree (+)
Tool Bar (*)
Split Menu Button (*)
Choice Button (^)
Border (^)
Split Pane (-)
Combo Box (+)
Scroll View (+)

As you can see there are quite a range of controls for the next release! However there is no calendar and tab controls, and some of the controls mentioned above may appear in the internal com.sun package instead. Also note that any controls that end up in the com.sun package are to be considered experimental, just like all the other APIs in com.sun. Luckily from the community there is a Calendar Picker control that is good enough for production use, even though it is currently in beta. For the tab control there is nothing present from the community although it is non trivial to create compared to the calendar control. I do wonder if the Grid Layout control is in fact a new layout.

On to the new and enhanced functionality the majority of the functionality is in the graphics area. Here is the list of functionality that will either, be in SoMa (+), not in SoMa (-), highly likely to be in SoMa (*), or may be in SoMa (^). Do note that this list may change as more information is known about what will be included/not included in SoMa.

Stage level keyboard and mouse event handlers (*)
Cloning/duplication of nodes (*)
Built in callback function variables for state change notification on all controls (+)
Control key functions are supported in TextBox control (+)
Controls can be autosized (+)
3D transformations for 2D graphics nodes (+)
Support for 3D bounds (+)
Can use an image as Paint with 9 slice scaling and tiling for controls (+)
Perspective and Parallel camera classes for 3D perspective transforms (+)
Support for 3D rotations (-)
Non visible controls do not recieve mouse clicks (^)
Performance tracker for Prism (+)
Camera/video and microphone capture (-)
Can remove a parent from a node (+)
Event bubbling/filtering (-)
Pixel access (-)
Support for maps as a core language construct (-)

Based on the 3D graphics functionality for the next release JavaFX will start to develop basic support for doing 3D graphics. Currently think of it as 2.5D where JavaFX is going through a transitional phase. Expect the next release after SoMa to have proper support for basic 3D graphics. Just imagine all the interesting possibilities with 3D graphics for JavaFX apps on desktop, mobile and TV :). There will definitely be other functionality that gets included in SoMa where there is no publicly available information about it.

Expect the JavaFX 1.3 release to not be too far away since the JavaFX TV plugin for NB (NetBeans) has been ready since Sept 14, and is going to be available when the JavaFX 1.3 NB plugin is integrated with the IDE. Already the installers are currently being developed for SoMa. It is only a matter of time (in days?) before JavaFX is released.

Coding Conventions For JavaFX Script

2009-10-03T20:17:00.000-07:00

With so many people developing applications using JavaFX Script recently it is time to look at some coding conventions. These conventions will include coding standards and best practices. Below I will establish coding conventions that are applicable to JavaFX Script, many of these will come from Java's coding conventions. Remember that what I am about to mention acts as a guide and should be followed where it is applicable.

Naming

Variable and function names should be in camel case (eg isInitialized). Constant names should be in upper case with each word separated by an underscore (eg TIMER_DURATION). Class and Mixin names should be in title case (eg AppUtils). Do note that in JavaFX Script both variables/constants and functions all share the same namespace, therefore you need to name carefully.

Ordering

In a JavaFX Script source file (.fx) the following should be ordered as follows:

Source file documentation
Class/mixin documentation
Class/mixin
Class/mixin constants
Class/mixin variables
Class/mixin initialisation blocks (init then postinit)
Class/Mixin functions

Functions should be ordered by functionality, eg:

function func1(arg1)
{
}

function func1(arg1, arg2)
{
}

function func1(arg1, arg2, arg3)
{
}

function func2()
{
}

When defining a multiple functions of the same name ensure that the function arguments are in exactly the same order in to avoid confusion (see the example above).

Indentation

In general 4 spaces should be used for indenting code. Avoid using lines that are longer than 80 characters, wrap up long lines instead, eg:

function aFunction(argument1, argument2, argument3,
argument4)
{
}

Long lines can be wrapped by the comma, open perenthesis characters.

Documentation

Preferably all public parts of the API should be documented since other people may use the API in their code. Only comment parts of the code that are not clear from reading it. Where ever possible use clear naming for classes, mixins, functions, variables and constants that indicate exactly what it does. This will help cut down on comments which can quickly go out of date through major code changes. Only include useful information in the comments that make it clear what a piece of code does, and why it is done that way. When handling exceptions that are going to be ignored always including a comment about why it is to be ignored.

Place comments just above the code being documented, not at the right hand side of the code, eg:

// Duration in seconds.
def DURATION;

Declarations

Place no more than one statement per line (this also apples to variable and constant declarations). Variable and constant declarations should only be placed at the beginning of a function, init, postinit, and class/mixin block. Do not declare variables and constants when they are first used (it can confuse people) like this:

if(arg1 > arg2)
{
var temp;

temp = arg1;
}

It is good practice to initialise variables when they are declared in order to make it clear what starting value or reference they have.

White Space

Each declared variable, constant, function should be on their own line, and two blank lines should separate variables/contants and blocks/functions, eg:

class aClass
{
    def const1;
    def const2;
var var1;
var var2;

    init
    {
    }

    postinit
    {
    }

    function func1()
    {
    }

    function func2()
    {
    }
}

Use two blank lines to separate class/mixin definitions in the source file. Each operator that is used needs to be surrounded by a space, eg:

minutes = seconds * 60;

Scoping

Keep internal class/mixin variables and constants private by omitting a scoping keyword unless there is a good reason to expose them externally. If a variable is to be read but not changed externally then use the public-read keyword, else if a variable is only allowed to be set once externally during object creation then use the public-init keyword. If a class/mixin variable or constant is meant to be accessed by sub classes/mixins then use the protected keyword.

Best Practices

Try to keep recusion in each function to no more than 3 in order to make it simple to understand and maintain
Try to keep nesting to no more than 3 levels with each object literal in order to make it clear what the sequential order is
Do use variables to reduce object literal nesting by having object literals refer to them instead of embedding an object literal
Avoid using names for variables, constants, functions and classes/mixins that are reserved by JavaFX Script if at all possible
Minimise the use of binding since it can degrade performance in an application
Use binding where a variable's value has to be constantly kept in sync with another variable since it reduces unessesary boilerplate code
Use perenthesis to clarify the operating order for an expression (eg if((a == b) and (c == d)))
Only use a single return statement (which is the last line) in a function, this makes a function easy to follow in sequential order

Ten Interesting Aspects Of JavaFX Script

2009-09-20T02:59:00.000-07:00

With the JavaFX Script programming language being cited by many as one of JavaFX's main strengths it is time to look at the language's interesting aspects. Some aspects will pleasantly surprise you, while others will come as a shock. Here are the 10 interesting aspects of the language.

1. Built-in support for generators

Comes in handy for generating multiple items. In particular it is commonly used for generating multiple nodes for use in layouts. Each generated node may be customized differently to accommodate different data being supplied for display.

2. Can run actions at a later time

Useful for displaying splash screens properly when there is some background processing going on. Below is some sample code that demonstrates this (in a script):

// Splash screen is displayed here.

public function run(args: String[]): Void
{
FX.deferAction(doBackgroundProcessing());
}

function doBackgroundProcessing(): Void
{
// Background processing is done here.
// Display the main screen, and then close the splash screen.
displayMainScreen();
}

What is important to remember here is that the function you are passing to the deferAction function must have a return type of Void. The deferAction function allows the splash screen to be fully displayed, and we can have the main screen displayed just after the splash screen is closed.

3. Can format dates in strings

Some concise syntax is provided by JavaFX Script to enable you to embed date formatting in strings. All of the date formatting options in the SimpleDateFormat class can be used, for example:

var formattedDate = "{%MM/dd/yy java.util.Date{}}";

In the above code a % char is used followed by the date format and a Date object to format a date in an expression. It may be possible in future JavaFX releases that regular expressions can be used as a string formatting option.

4. No support for static functions, variables and constants

An exception to this is with scripts, not classes. It would be interesting to know why JavaFX Script has no static support (an important design decision that was made?). Someone from the JavaFX development team would be able to shed more light on this.

5. Basic support for lookups (on nodes only)

Very handy when you do not want to keep a variable around, and want to temporarily access a node in order to run an action on it or make some changes. It may be possible that lookup support will be expanded to other areas (more general support) in future JavaFX releases.

6. Function parameters are immutable

At first this will be strange for those that have not done functional programming before. Since JavaFX Script has built in support for functional programming this makes sense. By making function parameters immutable it means that a function can safely perform operations on the parameter, without changing it thus when the program runs no funny side effects will occur.

7. Built-in support for mixins

Mixins are like interfaces except that you can define behavior in functions. Since mixins replace multiple inheritance it has made it easy to have a mixin or class inherit from multiple sources (mixins) in a predicable (clean) way. Do note that a mixin cannot be initialised.

8. First class internationalization support

This is one of the best features of JavaFX Script since it makes it a piece of cake to internationalize a program. Some unique syntax is used to make it easy to internationalize strings which hook up to a fxproperties file, for example:

Stage
{
title: ##"Window Title"
scene: Scene{}
}

The title property's value is tied to a key called "Window Title" which is prefixed by ## (indicates an internationalised string). Here is the corresponding resources_en.fxproperties file that contains that key:

"Window Title" = "Main Window"

Some people would consider this to be another form of lookup in JavaFX Script. It is very much up to debate if this is the case.

9. Built-in support for animation

It is much easier to handle animation when it can be done directly without the need for a library (less abstraction), and most properties can be manipulated via binding for use on a timeline. The unique JavaFX Script syntax provides a concise way to animate nodes quickly in a scene graph.

10. Built-in support for binding

Makes it very easy to keep properties in sync, thanks in part to the unique JavaFX Script syntax. Even better is the fact that you do not need to create any tedious, and error prone boiler code to do it which helps to reduce overall maintenance.

Some of the formatting of this blog post is incorrect since I am unable to get the editor to properly change the formatting (major bug). Hopefully this will be resolved in time for my next blog post.

HTML 5 And RIA

2009-09-07T15:15:00.000-07:00

With so much information available on HTML 5 at the moment, in particular with the rumor of HTML 5 killing off all the other major RIA technologies (JavaFX, Silverlight, Flex). Now is a good time to discuss the advantages and disadvantages between the two. Currently HTML 5 is being touted as the one technology to do everything, however to be honest it will be good at some areas, worse in others. Certainly many people will get a reality check once HTML 5 is used in real world projects. This reminds me of when Java was introduced since in a way history is repeating itself all over again.

For the basis of this article I will be commenting on what was mentioned in the well written article titled, HTML 5 Starts Looking Real. Be warned that while the web page is loaded that you may experience a very sluggish web browser, due to the Flash ads that have been embedded in the article. So be sure to close the web page as soon as you have read the article.

In the referenced article there is a lot of coverage on openness and why it matters, the author seems to think that HTML 5 will take over because it is fully open. But there is much more to it than having a technology that is open. While I am a firm beliver in using open source as much as possible, and where it makes sense to do so, I understand that to get the best out of software development you need to have balance.

Often this balance means being prepared to use something that may not be fully open sourced. Some of the best software/technologies in use today are not fully open sourced. If a software/technology is partly open sourced does that completely stop you from utilising it? Obviously that may not be a yes answer to that question since you may see some advantages with having some parts closed sourced, even though you prefer them to be open. Although all of the RIA technologies are not fully open sourced that does not stop people from using them.

As the referenced article mentions, flexibility is another major part to take into consideration when looking at HTML 5 and RIA technologies. Especially if you need to develop a highly sophisticated applications that tie into the underlying software/hardware platform. This is going to be an area that places HTML 5 at a significant disadvantage in relation to RIAs since it will largely be constrained to the capabilities of the web browser used by the user.

Advantages Of Using HTML 5

Can easily have search engines go through all content
Minimal learning curve since most people already know the basics of HTML
Cheaper budget with using any free tool that can handle HTML
Large pool of developers to choose from when forming a development team
Easier to deploy HTML 5 applications since HTML is supported natively by the web browser, and does not require any installation

Disadvantages Of Using HTML 5

Limited ability to take advantage of new software development techniques since the choice of programming languages is limited
Will take longer to evolve since it is a combination of standards that are developed by different groups
User experience will greatly vary between software/hardware platforms (lack of consistency)
Limited flexibility and power since HTML is constrained to the capabilities of the web browser
Poor choice for mobile platforms since it will not take advantage of the hardware and will provide very limited capabilities
Inconsistencies of HTML being implemented between web browsers (different parts of the standard are implemented)
Performance is largely constrained to the bandwidth that is available to the user
User may need be connected to use an HTML 5 application
Very limited support for media formats
Lack of good tooling to be productive in developing large sized HTML 5 applications
Basic animation and media features

Advantages Of Using RIA

Can provide a guarantee of a reasonably good user experience (consistently) between different software/hardware platforms
Can evolve quickly since it is developed by a single company/organisation
Able to take advantage of new software development techniques since there is a wide range of programming languages to choose from
Good tooling for developing large sized RIA applications (increased productivity)
Good performance and power since RIAs can take advantage of the software/hardware platform
Reasonably consistent implementation of features between software/hardware platforms (including mobile)
Good performance with access to the hardware
Wide support for media formats
Excellent choice for mobile platforms since it will take advantage of the hardware features and can provide a reasonable user experience
Advanced animation and media features

Disadvantages Of Using RIA

More difficult to deploy since a plugin will need to be installed first
Deployment of RIA applications are largely restricted to software/hardware platforms that have a plugin available
Smaller pool of developers to choose from when forming a development team
Increased learning curve since completely new technologies need to be learned
Search engines may be unable to go through content effectively

In general if you are planning to develop a simple application quickly that is not very sophisticated, and needs to be easily deployed then HTML 5 is a good choice. On the other hand if you are developing a highly sophisticated application, that requires a consistently good user experience then RIA is a good choice.

Also RIA should be favoured over HTML 5 if an application is going to be developed for mobile hardware platforms. Remember that a good user experience and the ability to have the application take advantage of the hardware (can be customised to the hardware), are the main considerations when developing applications for mobile.

What Next For JavaFX?

2009-08-20T12:34:00.000-07:00

After the current release of JavaFX (version 1.2) many people will be wondering where JavaFX will be heading next. Considering that Sun is remaining tight lipped at this stage on what to expect next with JavaFX I can only speculate on what could be included in the next release. Most of my information in terms of this speculation mainly comes from the JIRA bug tracking system and JavaFX team member blogs.

It is easy to understand why Sun is tight lipped on JavaFX development when you see what is new with Flex 4. For some reason there is no content being displayed with the referenced article, you may have better luck than I did. One cannot help but wonder if Adobe are obtaining the majority of their inspiration from JavaFX, it seems highly likely they did. Honestly I think that they have been intimidated by the recent success that JavaFX is currently enjoying, and are trying to bring some of that success to Flex. Flattery is the biggest form of imitation.

Based on what little information I have obtained so far this is what is most likely to appear in the next release of JavaFX (version 1.3, codename SoMa):

New graphics/rendering system (named Prism)
Basic 3D graphics APIs (from Prism)
Improved graphics performance (from Prism)
Use of GPU for graphics rendering (from Prism)
New 3D graphics system (based on OpenGL ES) that can be used on desktop, mobile, TV (from Prism)
Beta version of the highly impressive JavaFX Authoring tool (for Graphics Designers only - may be of use to Software Developers?)

The majority of improvements are in the area of graphics and performance like the previous release. After looking at the above list you are probably thinking that everything that is likely to be included comes from Prism. Just to give a quick background on Prism, it is a completely new graphics system built from the ground up to take advantage of the graphics hardware in the target machine. Prism was development around the same time that Scenario (the current graphics system for JavaFX) was being developed.

As you would expect with Prism using the graphics hardware (eg GPU) you should be seeing significantly better framerates, and less memory being used as a result. Currently many people are experiencing serious performance issues with the number of nodes being added to a scene (the biggest problem with Scenario). The more nodes that are added the slower the JavaFX application becomes, and the more memory that is used as a result. Eventually if one adds too many nodes this can result in the dreaded "out of memory error", sound familiar? Most of us that are developing applications using JavaFX can afford to wait for the next release, which does not have this issue since Prism is not affected by this.

It is a big if with the beta release of the JavaFX Authoring tool, but I would rather see a polished product as opposed to one that has clearly been rushed to the door too soon. Still it is highly beneficial to get the authoring tool released early for feedback so that it can become a high point of choosing JavaFX. After all we should aim to ensure that the authoring tool is the best designer tool around, PERIOD. It is time to target Flex Builder (based on the NetBeans GUI builder - Matisse) since we can do much better than what Adobe is currently doing.

JavaFX 1.2 On Linux (Update)

2009-08-02T13:09:00.000-07:00

Much to my surprise after performing some recent Ubuntu updates Java Web Start suddenly works again. I suspect it may be related to the GNU Java package, which was promptly uninstalled after experiencing problems compiling Java projects in NetBeans. By chance another attempt was made to run a JavaFX application through Web Start which worked perfectly without problems.

For those of you running JavaFX applications on Linux I would highly recommend you run them through Web Start. The reason for this recommendation is that the applet plugin for Firefox needs to become more robust. That is applets need to start without freezing the web browser, and more detailed feedback needs to be provided on the applet's loading progress (including the downloading of required resources). At least with Web Start you obtain a reasonably good level of feedback with the loading progress of an application, and if the application freezes then nothing else will be directly affected.

On the good news the Java Mobile 3 SDK is in the works for Linux. There is a screenshot of the SDK in action with one of the mobile emulators running via NetBeans. At the moment the JavaFX Authoring tool (for designers only) is currently in development. This tool will allow JavaFX applications to be designed visually (including the animations and bindings). It is a shame that the tool is not being targeted towards JavaFX developers since much of what was demoed at JavaOne 2009 is exactly what developers will be involved in doing daily. Certainly one would expect that the tool will be available on Linux since it is written in a mixture of Java and JavaFX. Details are currently sketchy on the tool but expect to hear more about the tool as soon as its released (as a stable version) at the same time JavaFX 2.0 (codename SoMa?) is released towards the end of this year.

I am predicting that if the JavaFX developers needs are met by the JavaFX authoring tool then they will be using it regularly. Not ideal unless there is a similar tool being released at exactly the same time for developers. In the worst case scenario the tool would need to satisfy the following developer requirements:

Allow assets (resources) to be accessed and stored through local storage (eg hard disk, USB key)
Generate fx source files for the view that are loosely coupled from the controller and model
The generated fx source files for the view must be easily customised by the developer, but must be readable in the tool after being customized
Be directly integrated with a set of usable mobile emulators that support all of the required JavaFX mobile APIs (including the set of APIs that make up the Mobile Services Architecture JSR)
Have "Matisse" like visual layout (a real must for custom dynamic layout)
Can easily add additional visual (and non visual) JavaFX controls to the control palette without writing any extra code just like in NetBeans
Customized visual binding via scripting (through JavaFX script)
Automate the tool through visual macros that can be customized at the code level (Scala is a possible candidate here)

If anyone has any ideas on what to include in the list please include it in the comments for this post.

JavaFX 1.2 On Linux

2009-06-03T12:32:00.000-07:00

Yesterday I had an excellent opportunity to give JavaFX 1.2 a spin on Ubuntu Linux (8.04 LTS - Desktop Edition). A 30 Kbps ADSL connection is used as the Internet Connection. All performance figures are informal and will greatly differ between Linux desktops. Some additional media codecs have been installed, which provide support for additional media file formats (including WMV and WMA) for GStreamer in Linux.

Before installing the JavaFX 1.2 SDK I installed JDK 1.6 (Update 14) which is a requirement for the JavaFX SDK. However the Java browser plugin had to be configured afterwards for Firefox, which is not as difficult as many might think it is. It is as simple as creating a link in Firefox's profile folder that points to the plugin itself. Do note that it is highly recommended that you setup the JDK_HOME and JAVA_HOME environment variables. After installing and configuring the JDK a test was in order to see if the browser plugin was properly functioning, which I can safely say passed with flying colours. You will need to have the Java browser plugin working in order to run most of the sample JavaFX applets on the official JavaFX site.

Installation of the JavaFX 1.2 SDK went smoothly, it was a matter of running the shell setup script and moving the SDK folder to the correct location. What I was most impressed with in terms of installation was the NetBeans IDE (with built-in JavaFX support). The experience was totally seamless, even the JDK was picked up by the IDE's installer and the JavaFX SDK was already included with the IDE. Right from the start of starting up the IDE I was able to create and run a JavaFX application in 15 minutes which included basic multimedia support.

In terms of multimedia support on Linux as many Linux users will know, is a hit and miss affair. When it came to testing multimedia support with JavaFX was was pleasantly surprised with the experience, since it had exceeded all my expectations. The following media formats that I had tested with my own JavaFX application work out of the box:

WMV (WMA has not been tested but is most likely to work)
MP4
OGG
FLV

Only the MP3 media format did not work as expected. During the first 3 seconds of playing an MP3 file everything sounded fine until stuttering occured. JavaFX has a built-in events to handle the stuttering effect. I have not used the event (inside the application) in light of the problem with the MP3 file. What I found strange is that on the official JavaFX site the JavaFX media player is used on Windows to play the videos, but on Linux I am forced to use the Flash media player. This appears to be due to the faulty platform detection code because I saw the following message on the web page, "Note: you have reached this page because you are on a platform not currently supported by JavaFX. If you think you have reached this page in error, please click here.".

The biggest highlight on the JavaFX SDK release for Linux has to be the performance, which is absolutely outstanding. From running applets to desktop applications I hardly noticed any pauses or freezes while the programs were running. My hat goes off to Sun for this since this is certainly one area where JavaFX can not only get ahead of other competitors, but also increase adoption by developers.

I personally decided to stress test the Java browser plugin by running 10 JavaFX applets (from the Samples section of the official JavaFX site) simultaneously. Most users will not run that many applets at once, however it is still useful to see how performance and stability fares when multiple applets are running. Firefox did not crash once when all ten applets were running and the reserved memory usage for the plugin (java_vm process) was not too bad at 153.2 MB. On average 15.32 MB is reserved for each applet. What needs to be done in memory usage though is to have memory released as soon as an applets exits (the Windows version already has this capability).

Now comes the part where many people will shudder (including me) at the thought of starting up/launching applets. In the past this has been a real archiles heel for Java desktop applications. I can proudly say after testing start times for applets (in the Samples section on the official JavaFX site) that startups are MUCH faster. In the worst case one applet took 14 seconds to startup. On the opposite side of the coin there were quite a few applets that took no longer than 3 seconds (there were even ones that only took a second!).

Upon attempting to run all sample applets (on the official JavaFX site) I found that most applets would startup and run properly. Here are following samples that do not run properly:

Draggable MP3 Player (cannot play any MP3 music and cannot drag applet out of the web browser)
Keystroke Motion (applet does nothing when applet is selected and keys are entered)
Video Cube (refuses to play an FLV file whic)

The biggest downside for the deployment of JavaFX applets is that some of them totally freeze the web browser while starting up. If you are a user then you would totally be intimidated by this to the point where you would avoid any websites that freeze the web browser. The freezing normally occurs for no more than 3 seconds for most applets. This freezing has to be resolved in time for the next update of the JRE for Linux. By that time JavaFX developers will be ready to test deployment of applets.

As for awful surprises all JavaFX applications that I have launched through Java Web Start fail to start up at all. All of these failures have once thing in common, the MalformedURLException is displayed as the root cause of the failure. Java Web Start was not broken like this in previous releases of the JRE for Linux. It will certainly be a top priority to fix Java Web Start for Linux in time for the next release of the JRE.

Integration of JavaFX applications with the OS is a real plus. I can copy and paste text to and from a JavaFX Text Box, I can even copy and paste text via drag and drop. Do note that text cannot be selected by word with the keyboard or mouse. Creating full screen applications does not currently work properly (the title bar is missing). Maximizing and minimizing the application works as expected.

For some reason media streaming is hit and miss with the Media Box sample (on official JavaFX site). During the first few seconds of playing the video the sound plays just fine before it cuts out. The Video Cube sample fails to play the FLV file (a MediaUnsupportedException is displayed in the message) even though it is playable in my JavaFX desktop application.

Overall I would highly recommend the JavaFX SDK for software developers that are using Linux despite that fact that Sun has classified the SDK as being in Beta. In my opinion I consider the SDK to be a release candidate, but that is up for debate by other developers. Despite the deployment situation being bad developers can very comfortably create JavaFX applications right away. In the mean time look out for the next update of the JRE which should improve deployment from being bad to not too bad. By that time you can safely test the deployment of JavaFX applications.

JavaFX 1.2 is a HUGE step forward which should help with its adoption, and advocacy even though it is a little bit behind its competitors in some areas (deployment, UI building), but ahead in others (performance, component architecture, binding, cross platform support). It is very good to see JavaFX rapidly catching up to its competitors, and that Larry Ellison is extremely enthusiastic about it, to the point where he is prepared to make a full commitment (this includes development). Now it would be nice to see a SVG to FXM converter (many people are using Inkscape as an open source alternative to Photoshop - this is starting to become common place with JavaFX) with the next JavaFX SDK release, and the GUI designer which I am VERY eager to try out.

A note to Sun about support for developing JavaFX mobile applications on Linux. Linux has a very large presence in the mobile development area. Since the first versions of the CDLC and CDC SDKs (before they were rolled into the JME SDK) there has been solid support for Linux. It is very disappointing to see that there is hardly any support for Linux with the JavaFX SDK on the mobile side. Also there is no JME SDK (version 3) for Linux. I am expecting that there will be an actual JavaFX mobile emulator, as well as a release of JME SDK (version 3) for Linux by the time the next JavaFX SDK is released.

While JavaFX mobile applications can be developed on Linux (in theory) there is no way to properly test and deploy them on a mobile emulator, or mobile device. Considering that JavaFX is going to shake up the mobile development scene for the better, would it not make sense to provide a good level of support for Linux in order to have widespread adoption?