Visage - A Refreshing Change

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

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

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

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

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

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

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

JavaFX 2 - The Good, Bad, And Ugly

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


Good

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

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


Bad

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

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

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


Ugly

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

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

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

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

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

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

Conclusion

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

Use Of JavaFX Script

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

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

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

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

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

Scripting In JavaFX Script

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

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

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

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

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

Coding Conventions For JavaFX Script

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:

1. Source file documentation
   
2. Class/mixin documentation
   
3. Class/mixin
4. Class/mixin constants
5. Class/mixin variables
6. Class/mixin initialisation blocks (init then postinit)
7. 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

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.