05 December 2016

Simple REST Server With Kotlin


With micro services being the latest important development in Software Engineering anyone doing server side development needs to be involved in this area. One of the major areas where Kotlin is being used is in server side development, especially micro services. This post will be covering how to create a simple REST server using the following technologies:


  • Gradle (any 2.x version)
  • Kotlin v1.0.5-2 (stable version)
  • Grizzly v2.3.28 (embedded HTTP web server)
  • Grizzly Jersey Container v2.23.2 (JAX-RS implementation for Grizzly)
  • Jackson v2.23.2 (JSON library)
  • Linux PC (using Debian, Ubuntu or Linux Mint)

Setup Project Directory

  1. Create a project directory called hello_rest_server
  2. Copy the Gradle wrapper directory and the gradlew file to the project directory
  3. In the project directory create a file called settings.gradle containing rootProject.name = 'hello-rest-server'
  4. Create a Gradle build file called build.gradle in the project directory containing the following:

-------------------------------------------------------------------------------------
group 'org.example'version '0.1-SNAPSHOT'
buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:1.0.5-2'    }
}

apply plugin: 'kotlin'apply plugin: 'application'
repositories {
    mavenCentral()
}

dependencies {
    compile 'org.jetbrains.kotlin:kotlin-stdlib:1.0.5-2'    compile 'org.glassfish.grizzly:grizzly-framework:2.3.28'    compile 'org.glassfish.jersey.containers:jersey-container-grizzly2-http:2.23.2'    compile 'org.glassfish.jersey.media:jersey-media-json-jackson:2.23.2'}

// A Task to run the program.run {
    mainClassName = 'org.example.hellorestserver.RestServerKt'    //args = ["arg1", "arg2"]}

// A Task to create a JAR file for the program.jar {
    from configurations.compile.collect { zipTree it }
    manifest.attributes 'Main-Class': 'org.example.hellorestserver.RestServerKt'}
-------------------------------------------------------------------------------------


Text version:

-------------------------------------------------------------------------------------
group 'org.example'
version '0.1-SNAPSHOT'

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:1.0.5-2'
    }
}

apply plugin: 'kotlin'
apply plugin: 'application'

repositories {
    mavenCentral()
}

dependencies {
    compile 'org.jetbrains.kotlin:kotlin-stdlib:1.0.5-2'
    compile 'org.glassfish.grizzly:grizzly-framework:2.3.28'
    compile 'org.glassfish.jersey.containers:jersey-container-grizzly2-http:2.23.2'
    compile 'org.glassfish.jersey.media:jersey-media-json-jackson:2.23.2'
}

// A Task to run the program.
run {
    mainClassName = 'org.example.hellorestserver.RestServerKt'
    //args = ["arg1", "arg2"]
}

// A Task to create a JAR file for the program.
jar {
    from configurations.compile.collect { zipTree it }
    manifest.attributes 'Main-Class': 'org.example.hellorestserver.RestServerKt'
}
-------------------------------------------------------------------------------------

Create Kotlin Source Files


Create the following directory structure in the project directory, along with the kt files as shown below:

src
├── main
│   ├── java
│   ├── kotlin
│   │   └── org
│   │       └── example
│   │           └── hellorestserver
│   │               ├── HelloResource.kt
│   │               └── restServer.kt
│   └── resources
└── test
    ├── java
    ├── kotlin
    └── resources


To begin restServer.kt will act as the entry point file for the REST server, which will be edited first by adding the following code:

-------------------------------------------------------------------------------------
package org.example.hellorestserver

import org.glassfish.grizzly.http.server.HttpServer
import org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpServerFactory
import org.glassfish.jersey.jackson.JacksonFeature
import org.glassfish.jersey.server.ResourceConfig
import javax.ws.rs.ProcessingException
import javax.ws.rs.core.UriBuilder


fun main(args: Array) {
    val HOST = "localhost"    val PORT = 9000    val baseUri = UriBuilder.fromUri("http://$HOST/").port(PORT).build()
    var server: HttpServer? = null
    try {
        server = GrizzlyHttpServerFactory.createHttpServer(baseUri, createConfiguration())
        println("REST Server Address: $HOST:$PORT")
    } catch (ex: ProcessingException) {
        println("Server Error: ${ex.message}")
        println("Exiting REST server...")
        server?.shutdown()
    }
}

private fun createConfiguration(): ResourceConfig {
    val config = ResourceConfig(HelloResource::class.java)

    // Optional but good practise to manually specify the JSON mapping implementation to use.    config.packages("org.example.hellorestserver").register(JacksonFeature::class.java)
    return config
}
-------------------------------------------------------------------------------------


Text version:

-------------------------------------------------------------------------------------
package org.example.hellorestserver

import org.glassfish.grizzly.http.server.HttpServer
import org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpServerFactory
import org.glassfish.jersey.jackson.JacksonFeature
import org.glassfish.jersey.server.ResourceConfig
import javax.ws.rs.ProcessingException
import javax.ws.rs.core.UriBuilder


fun main(args: Array) {
    val HOST = "localhost"
    val PORT = 9000
    val baseUri = UriBuilder.fromUri("http://$HOST/").port(PORT).build()
    var server: HttpServer? = null

    try {
        server = GrizzlyHttpServerFactory.createHttpServer(baseUri, createConfiguration())
        println("REST Server Address: $HOST:$PORT")
    } catch (ex: ProcessingException) {
        println("Server Error: ${ex.message}")
        println("Exiting REST server...")
        server?.shutdown()
    }
}

private fun createConfiguration(): ResourceConfig {
    val config = ResourceConfig(HelloResource::class.java)

    // Optional but good practise to manually specify the JSON mapping implementation to use.
    config.packages("org.example.hellorestserver").register(JacksonFeature::class.java)
    return config
}
-------------------------------------------------------------------------------------

Above the host name and port number are stored in constants and referred to in the UriBuilder.fromUri function which creates a URI object. An attempt is made to start the server by creating an HttpServer object via the GrizzlyHttpServerFactory.createHttpServer function. Only 2 arguments need to be passed through, a URI and the resource configuration (ResourceConfig object).

Grizzly needs the resource configuration in order to know how to do the REST resource mapping. In this case the HelloResource class object (Java version) is passed as an argument to the ResourceConfig constructor in the defined createConfiguration function. If the server fails to start then a ProcessingException will be thrown. When that situation occurs the server error message is outputted to the console, followed by shutting down the server before exiting the program.

Now setup the REST resource mapping by adding the following code to HelloResource.kt:

-------------------------------------------------------------------------------------
package org.example.hellorestserver

import javax.ws.rs.GETimport javax.ws.rs.Pathimport javax.ws.rs.Producesimport javax.ws.rs.QueryParamimport javax.ws.rs.core.MediaType
import javax.ws.rs.core.Response

@Path("/hello")
class HelloResource {
    @GET    @Produces(MediaType.APPLICATION_JSON)
    fun getMessage(@QueryParam("name") name: String): Response {
        println("Processing request...")
        return Response.ok(mapOf("msg" to "Hello $name! :)"), MediaType.APPLICATION_JSON).build()
    }
}
-------------------------------------------------------------------------------------


Text version:

-------------------------------------------------------------------------------------
package org.example.hellorestserver

import javax.ws.rs.GET
import javax.ws.rs.Path
import javax.ws.rs.Produces
import javax.ws.rs.QueryParam
import javax.ws.rs.core.MediaType
import javax.ws.rs.core.Response

@Path("/hello")
class HelloResource {
    @GET
    @Produces(MediaType.APPLICATION_JSON)
    fun getMessage(@QueryParam("name") name: String): Response {
        println("Processing request...")
        return Response.ok(mapOf("msg" to "Hello $name! :)"), MediaType.APPLICATION_JSON).build()
    }
}
-------------------------------------------------------------------------------------

Above the HelloResource class handles the REST resource mapping for the /hello path (part of the URI). There is a single function (getMessage) which handles a GET HTTP request that contains a single URI query parameter called name. All that the function does is output a message to the console, and returns a message (as a HTTP 200 response via Response.ok function) in JSON (specified in the Produces annotation) form.

To start the REST server execute ./gradlew run in the project directory. Use the curl command to test out the server (eg curl localhost:9000/hello?name=Elvis). Exit the server using the Ctrl+c keyboard shortcut in the same console running the server.

20 November 2016

Kotlin Scripting


Many people won't be aware that Kotlin has scripting support, which includes the REPL. If you run the Kotlin compiler without any arguments you end up in the REPL (Read Evaluate Print Loop) environment, which is similar to Python's.

Kotlin REPL

Within the REPL basic expressions can be executed. Can even do block declarations. Some of the BASH keyboard shortcuts work, like Reverse Search (Ctrl + r) which will bring up the last line of code that was entered if it matches the search terms entered. As is the case with Python the order of code execution is from top to bottom. Currently documentation on Kotlin scripting is very scarce. The best place to look is on the Gradle website.

Kotlin REPL running code

Compilation time with each line of code that is executed is very FAST. So fast that there will be some situations where it is significantly quicker to try things (eg prototyping) out in the REPL rather than writing and executing a basic Kotlin program in a IDE. There is a file format called kts that represents a Kotlin Script which can be run in the REPL via the :load command. Can also run kts files using the Kotlin Compiler. Do note that the :load command does not accept a path to the kts file which contains spaces. Hopefully that will be fixed in a future Kotlin release.

For a more advanced/functional Kotlin REPL use the one provided by IntelliJ (is available in the open source Community edition). Despite being slower and not as stable as the original it does make it much easier to execute/manipulate blocks of code, and provides code completion as well as pop-up API documentation. Also all code is highlighted depending on the syntax highlighter that is used.

Kotlin REPL in IntelliJ

Kotlin REPL in IntelliJ - Running code

Be aware that you may encounter the infamous IDE lock-up bug where you do some code completion, and the IDE doesn't respond to keyboard and mouse events. Should such a situation occur then the IDE will need to be force closed and restarted. Not sure if the bug is fixed in the current IntelliJ Kotlin plug-in but be on the lookout just in case.

IntelliJ doesn't have a template for creating a Kotlin Script project so you will have to improvise by doing the following in IntelliJ:

  1. Goto FileNewProject…
  2. On left side select Empty Project
  3. Click Next button
  4. Enter in the project's name and location
  5. Click Finish button
  6. Goto FileNewModule…
  7. On left side select Kotlin
  8. On right side select Kotlin (JVM)
  9. Click Next button
  10. Enter in Kotlin for the module name
  11. Click Finish button
  12. Create a folder called src


A big advantage with the improvised Kotlin Script project is that you will have a clean REPL environment that only includes the Kotlin default imports by default. Also you have a central place to manage Kotlin Scripts should you want to keep existing code snippets to run in the future. Do note that kts files in the project cannot be accessed in the REPL (includes items like classes, variables, constants etc).

In an ordinary Kotlin project the REPL can access items (classes, variables, constants etc) from a kt file provided the source file is pre-compiled and is in a package. You will need to be careful when importing an item to avoid name-space clashes, especially at the top level.

Kotlin REPL in IntelliJ - Accessing module item

One last thing to mention is that Kotlin can be used for scripting at the terminal level via the kscript project. Below is a sample script from the project:

--------------------------------------------------------------------------------------------------
#!/usr/bin/env kscript
//DEPS com.offbytwo:docopt:0.6.0.20150202,log4j:log4j:1.2.14

import org.docopt.Docopt
import java.util.*


val usage = """
Use this cool tool to do cool stuff
Usage: cooltool.kts [options]  ...

Options:
 --gtf      Custom gtf file instead of igenome bundled copy
 --pc-only           Use protein coding genes only for mapping and quantification
"""

val doArgs = Docopt(usage).parse(args.toList())

println("Hello from Kotlin!")
println("Parsed script arguments are: \n" + doArgs.joinToString())
--------------------------------------------------------------------------------------------------


23 September 2016

First Look At Kotlin


Has been a long time since I found an interesting programming language which changes the way you approach solving problems in certain areas. Last time I was into JavaFX Script however it didn't take off as expected mainly due to the Java community not embracing it in general, the language was too specific (domain orientated), and not enough resources were being allocated to improving/supporting it. Also when trying to use JavaFX Script in projects the interoperability with the Java ecosystem (JPA, JAX-RS etc) often ended up being a show stopper.

By chance when looking at alternatives for Android development I discovered Kotlin. Kotlin is reasonably easy to learn with its difficulty sitting in between Python and Java. What ended up being really attractive about the language is its pragmatism/industry driven approach to software development. Many features in Kotlin are very well thought out with every single one being a result of Software Engineering experience in the industry (ICT). There aren't many programming languages that manage to balance conciseness with readability. You end up more often than not reading rather than writing code.

One of my favourite Kotlin features is Delegated Properties, specifically storing properties in a Map. Below is an example of this:




Text Version:

class Person(val map: MutableMap){
     var firstName by map
     var lastName by map
     var age by map
}

fun main(args: Array){
     val map = mutableMapOf(age to 20, firstName to Joe, lastName to Bloggs)
     val aPerson = Person(map)

     map["lastName"] = "Burke"
     aPerson.firstName = "Jane"
     println("Person: ${aPerson.firstName} ${aPerson .lastName}, ${aPerson .age}")
     println(Person age is Int: ${aPerson.age is Int})
     println("Map -> First Name: ${map["firstName"]}")
}



What you have above is an example of bidirectional Data Binding (sort of), which opens up a number of interesting real world applications like binding a database model (the model class, not the actual database) to a view. Despite the MutableMap using mixed types for the values it works just fine for the Person properties that rely on type inference via delegation. Blogger unfortunately doesn't have syntax colouring support for Kotlin code, is Google planning to fix this?

Some people view Kotlin as a statically typed version of Python however it isn't entirely warranted. If anything Kotlin is most similar to Swift. Even the language goals are very similar:

  • Concise
  • Safe
  • High performance
  • Versatile
  • Tooling
  • Interoperable

Kotlin documentation isn't too bad (the quality of the references is good) however it is seriously lacking a decent tutorial. Confusingly the navigation of the documentation section of the Kotlin website is all over the place. The Kotlin Koans for instance is in the Tutorial area instead of the More resources area. There appears to be a “Getting Started Guide” in the Reference area. If it is a tutorial then it needs to be moved to the Tutorial area.

Some Kotlin design decisions are questionable/controversial. Closed (sealed) classes are one decision which is very odd considering that there are a significant number of libraries/frameworks that rely on open class design, and Software Engineers frequently design software using an open class architecture anyway. Another one is Data Classes where some implemented functions are included for free (toString, equals, hashCode), and object de-structuring is automatically supported, which should be in ordinary classes instead. Using Data Classes causes severe issues (no class inheritance etc) that would be easily avoided by going with ordinary classes anyway.

Below is a list (not exhaustive) that shows who is using Kotlin:


Companies

  • Amazon
  • Google
  • Netflix
  • NBC (NBC News, TODAY, and Nightly News Android apps)
  • American Express
  • Pivotal (own Spring framework)
  • Expedia
  • Square
  • 3D Robotics (3DR Tower Android app not available in Google Play)
  • Basecamp (creator of “Ruby On Rails”), Basecamp Android app
  • Prezi
  • JetBrains
  • MongoDB
  • BQ (various Android apps not available in Google Play)
  • Meizu (various Android apps not available in Google Play)
  • App Foundry
  • GMC
  • Allegro Group
  • Bryx 911 (first responder Android app not available in Google Play)
  • Trapit (builds Android apps for some fortune 500 companies using Kotlin)
  • Farm Logs (Android app not available in Google Play)
  • Nulab Inc (Android app not available in Google Play)
  • Pinterest

Software Projects

  • Anko (official Android application development library for Kotlin)
  • Kotter Knife (Android view binding library for Kotlin)
  • TornadoFX (JavaFX library for Kotlin)
  • MapDB (embedded NoSQL DB for the JVM)
  • Requery (SQL query and persistence library which has Kotlin support)
  • Exposed (official SQL library for Kotlin)
  • Spec (official unit testing framework for Kotlin)
  • Kara (web framework for Kotlin)
  • Quasar (JVM concurrency library which has Kotlin support)
  • Spring Boot (micro services framework which has Kotlin support)
  • Gradle (version 3 onwards has support for developing plug-ins using Kotlin)
  • RxKotlin (RxJava bindings for Kotlin)

Android Apps

Kotlin Jobs (Possible Users)

One of the major surprises with Kotlin is the significant interest in the language from the Android Development community. Certainly helps when Jake Wharton (likely the most well known person in the Android Development community) is endorsing Kotlin. Many in the community want Google to support Kotlin as an alternative to Java.

In Fragmented postcast #20 an out of blue question was asked by one of the presenters, “When is Google going to support Kotlin in Android Studio?”. Why hasn't Kotlin been covered in an Android Developers Backstage podcast yet? Since late last year there have been a few Googlers frequently visiting the Kotlin slack channel, which has recently celebrated reaching the 4000 registered users mark.

As you can see it is highly unlikely Kotlin will be going away considering the sheer number of major companies and Android apps using Kotlin. If anything this shows that all Java developers should be seriously looking into using Kotlin for some projects if they haven't done so already. Kotlin is highly likely to represent the biggest change to the JVM landscape after Java 8.

27 September 2015

Moto G 2nd Gen Android 5.1 Update


Currently the Moto G 2nd Gen is on Android 5.0.2 and there is a maintenance release gradually being rolled out, however the release isn’t available to the XT1068 (network unlocked international variant) as of 25th September 2015. Maintenance release only fixes the StageFright issue and doesn’t provide an update to Android 5.1. While Motorola’s initial response to the StageFright issue is very good with providing information about the issue and a proper workaround their follow up has been very poor.

Motorola have been very slow in making the maintenance release available. So slow in fact that it is taking over a month so far to get the release distributed which is unacceptable. StageFright fix was released by Motorola for testing by mobile telcos on 10th August 2015, which isn’t applicable to the XT1068. Should only take at most a week to to distribute security fixes. Even then that is a bit too long when it comes to fixing security issues on a mobile device.

When it comes to finding out information about Android updates for the Moto G 2nd Gen it is very difficult to obtain the right information. Very hard to navigate Motorola’s website for software update information, and even worse when you do get there more often than not the information is inaccurate. The UI (User Interface) for the update section of Motorola's website differs widely between different countries. Why can’t Motorola use a single UI for the update section that applies to all countries?

Very quickly discovered that the Motorola Community forums are not an appropriate place to obtain update information, in particular on Android 5.1. For one thing while there should be some Motorola employees working in the forum occasionally. There is no clear evidence of this happening. Google get that part right on their forums where you can clearly see any posts made by Google employees. With Motorola anything goes, it is a real jungle out there. Any new thread created seems to get mysteriously removed if it is related to Android updates.

With my own experience of contacting Motorola about software updates for the XT1068 I discovered that their Customer Service department can’t communicate with their Software Update department and vice versa, for some strange reason. At one point the service representative was trying to help me with obtaining software update information for the XT1068 via the IMEI number but couldn’t because of the communication issue mentioned above. Seemed as though at times the responses were very robotic in nature as though I wasn’t communicating with a real human.

Currently the Moto G 2nd Gen hasn’t received the Android 5.1 update yet. It is the only Moto series smartphone (apart from Moto G 2nd Gen with 4G) to not receive the update. Below is a list of Moto smartphones where the update is either available or is currently being rolled out:



Some users are fed up with Motorola not sorting out the critical app management and memory leak issues (there are no workarounds) for the Moto G 2nd Gen. Has been mentioned on the Motorola Community forums. In fact there is a hot thread which is in the top ten that covers this issue, which Motorola aren’t taking seriously and the maintenance release doesn’t fix the issue. Many users find that the Moto G 2nd Gen on Android 5.0.2 is unusable.

Upon close research of the issue it was found that Motorola caused the issues (it isn’t an Android one) by fiddling around with a setting called minfree, which they shouldn’t have messed around with. As the old saying goes, If it ain’t broke don’t fix it!. Android 5.1 properly fixes the issues for the Moto G 2nd Gen which Motorola have yet to make available. Motorola MUST provide the Android 5.1 update for the Moto G 2nd Gen.

Android 5.1 (released on 9th March 2015) introduces dual SIM support. The New Zealand version of the Moto G 2nd Gen (XT1068) can take 2 SIM cards. Motorola’s software for handling dual SIMs is unofficial (not supported by Android). It is astonishing that the Moto G 1st Gen with 4G (the variant with dual SIMs) has an update available to Android 5.1 before the Moto G 2nd Gen (XT1068). Where are your software update priorities Motorola?

To make matters worse (by putting the boot into Moto G 2nd gen users) Motorola have made the very embarrasing move of updating the Moto E (1st and 2nd Gen) a budget smartphone to Android 5.1 before the Moto G 2nd Gen which is a mid range smartphone. Absolutely appalling behavior by Motorola which is unacceptable. Once again this shows that Motorola don’t have their software update priorities sorted. A manufacturer should NEVER make software updates a higher priority for a budget level device over a mid range one. There may be light at the end of the tunnel with Android 5.1 currently undergoing testing on the Moto G 2nd Gen.

New Zealand consumer laws are not recognised by Motorola. In the warranty document for the Moto G 2nd Gen (XT1068) no New Zealand consumer law is mentioned and a limited warranty is applied to New Zealand, when in fact a full warranty applies (24 months) under the CGA (Consumer Guarantees Act. Samsung is a good example of a manufacturer that correctly mentions the New Zealand consumer laws and the correct warranty period (24 months) for their smartphones.

Considering the fact that the Moto G 2nd Gen is unusable with the software causing critical memory leaks and improper SIM support etc, Motorola have failed to comply with section 6 (goods are of acceptable quality) of the CGA. Motorola can easily meet their obligations under the CGA by providing an Android 5.1 update for the Moto G 2nd Gen.

An ultimatum will be given to Motorola which will be that their head of the Software Update department responds to the blog post within 2 days (reasonable timeframe), with the following requirements being met:

  • An in depth explanation as to why the Moto G 2nd Gen hasn’t received the Android 5.1 update yet
  • Explanation as to why Moto G 2nd Gen users have been treated very badly compared to other Moto users when it comes to software updates and customer support in general
  • What Motorola WILL do to ensure that the Android 5.1 update arrives for the Moto G 2nd Gen before the Android 6.0 update is rolled out to selected smartphones
  • Steps that Motorola will take to ensure that a lower level device doesn’t receive a software update before a higher level device in the future
  • How Motorola will improve its communication with its customers

If Motorola fails to respond properly in a timely manner then the Moto G 2nd Gen Android 5.1 update issue WILL be escalated. Some possible options to take as part of the escalation include coverage of the issue on Fair Go (screens on public TV nationwide and internationally) and the Disputes Tribunal.

01 April 2014

JavaME 8 SDK Supports Linux

Have received some excellent news regarding JavaME 8 Embedded support for Linux. In previous versions of JavaME support for Linux was dropped for the SDK with no particular reason given as to why. Now support for Linux is coming starting with the JavaME 8 SDK, which will likely arrive in around 3 months time. Typical policy with release dates on Oracle products and services is that no specific release dates can be given. The SDK could take much longer to arrive than expected.

In the JavaME 8 SDK for Linux two emulators will be included for developing/testing embedded programs. One for Raspberry Pi and the other for the Beaglebone Black. Sharp eyed readers may have spotted the new support for the Beaglebone Black that has been a long time coming. While the Raspberry Pi is OK for basic embedded projects there are many projects that require more comprehensive hardware, which the Raspberry Pi lacks (eg reasonable number of GPIO pins, advanced power management support, internal storage).

Coincidentally at around the same time important announcements are being made by the Beaglebone Foundation on programming language support for the Beaglebone Black. JavaScript support will be dropped in favour of Python and Java. This has been a long time coming since many developers were very unhappy with the current language support. Especially for a language like JavaScript which only works effectively for Web Applications. Many developers were already doing projects written in Python instead of JavaScript which placed the foundation in a very embarrassing position.

For some time the foundation has been going against the needs of developers by forcing them to create programs using JavaScript that has a dependency on the Internet. Many developers found this unacceptable since most of the projects they were developing needed to be fast, run for long periods of time, and have good low level hardware support. The announcement can't come soon enough since many of the developers were switching to the Raspberry Pi even though it wasn't the best solution for their embedded projects.

Can't wait to see what can be created using the Beaglebone Black, and JavaME 8 Embedded. Looking forward to creating a basic weather station as my first venture into embedded development. For those that are too impatient to wait the the stable JavaME 8 SDK to arrive (with Linux support) there is a preview version coming that will arrive in a few weeks, so hold tight a while longer.

23 January 2014

Linux Mint Switch

Been using Ubuntu for over a decade, however Canonical have made some controversial decisions that have caused me to seriously look at making the switch to an alternative Linux distribution. Canonical started making some of these bad decisions with Ubuntu 12.04. Unity had made its debut and I was prepared to give it a fair spin before passing judgement. Many Ubuntu users greatly disliked Unity with a vengeance.

After using Unity for at least a month I had experienced many of the problems that users experienced. For starters it was very difficult and time consuming to launch programs through a dizzying array of filters that had to be applied, otherwise every program would be shown, or not at all. One essential requirement for a desktop is to allow some customisation to suit a users needs. Customising Unity wasn't possible in any shape or form. No program was provided to do this.

What really provided grief was the Houdini global menu system that every installed program had to support, provided it had menus. If a window had a menu bar then the menus would be hidden at the very top. You would need to be aware that the program provides menus. Also accessing a menu is an exercise in frustration with ensuring the mouse pointer is in exactly the right place to make the menu bar appear.

To make matters worse the performance of Unity was downright sluggish (eg too much CPU used when moving a window, slow to startup), and windows would be garbled in a multi-monitor setup with some computers. Programs couldn't be made to show full screen. On one computer Unity would crash regularly. Unity certainly wasn't what I would call a production ready desktop with its major usability, stability and performance problems.

Not everything about Unity was a bad experience. Liked having a bar where you could quickly and easily see/select running programs by their icon, which is much nicer than the traditional taskbar approach when you have many programs running. Easy to logout, shutdown etc from the same place as in previous versions of Ubuntu. Unity is very aesthetically pleasing to look at, which looks as though it has been done by professional Graphics Designers.

Currently I have been using Gnome Shell (version 3.4) as a replacement to Unity which is working out well for me despite having to install some extensions to sort out all the major issues. The performance, stability, and the sane UI (User Interface) of Gnome Shell have been exactly what I was after but didn't get with Unity. To top it all off Gnome Shell has a professional/sleek look about it. Unfortunately the recent versions of Gnome Shell have made a habit of removing useful features, and have stuffed up existing ones making the UI volatile. The program launcher is a good example of this.

Had the experience of trying out the Cinnamon desktop with Linux Mint (version 13). So far I have been impressed with the fact that the desktop brings out the best of the old and new desktops in a way that makes it modern without being slow, difficult to use, and unstable. Although Cinnamon has its own issues just like any other desktop it is improving at a good pace without providing a Faulty Tower UI. Looking forward to the next set of improvements made with Cinnamon.

Canonical's recent efforts to focus on the mobile side with Ubuntu Touch, and rolling out their own unproven technologies which duplicates existing ones has given great cause for concern. There is a lack of focus on the desktop side for Ubuntu as can be seen with Unity and Mir as examples. While I realise that the GUI system (X Windows) needs an overhaul there is already a replacement that is getting close to being production ready (Wayland). Mir was created by Canonical out of a disagreement with what Wayland was doing. Very ironic that Mir is essentially doing many things the same way/similar as Wayland, what a wasted effort! Compatibility of existing/legacy programs remains up in the air with Mir. No wonder users are leaving Ubuntu in droves.

If Canonical continue to ignore their customers then more of them will switch to alternatives. Seriously pondering making the switch to Linux Mint (version 17) in order to get a sane UI that is production ready (fast and stable). With the way things are going with Ubuntu I don't have much confidence that Canonical will dramatically turn things around in time for Ubuntu 14.04.

01 November 2012

Oracle Certified Associate, Java SE 7, Programmer Study Guide Review

This book review covers Oracle Certified Associate, Java SE 7, Programmer Study Guide (ebook version) from Packt Publishing, which was recently published. Inside the book you will find it covers general topics for the Oracle Certified Associate certification, and provides sample questions in all chapters that one might find in the exam.

Some of the topics that the book covers include the following:

  • Java data types
  • Decision constructs
  • Classes
  • Handling exceptions
  • Arrays and collections


Excellent explanations are provided on the topics the book covers. Especially on memory management which is a key area to understand about the Java language. Most other books don't provide the same level of explanation on this topic as this book does. Plenty of good advise is provided on handling exceptions in a Java application. All key Java 7 features are covered in reasonably good detail.

What is highly unusual about this book is that it aims to be more than just a certification guide by also acting as a general reference. Unfortunately that aim is not reached since some language basics are not covered, which include using Generics and the other key collection classes (HashMap, HashSet etc).

Highly recommend this book if you are going for the certification since it provides good coverage of the topics that are covered, and a decent number of questions for each topic that test what is learned. However this book falls a bit short on covering all the Java language basics that one would expect from a general reference.

27 June 2012

Installing Ruby 1.9.3 In Ubuntu 12.04

Do note that the ruby1.9.1 package is for Ruby 1.9.3 (with Ubuntu 12.04). The version number at the end of the package name is for the ABI version of Ruby (1.9.1) that the package covers.

  1. Install ruby1.9.1 package for the Ruby language (also installs the libruby1.9.1 package that contains the standard Ruby library)
  2. Install ruby1.9.1-dev package in order to install gems that use native extensions

11 June 2012

Installing Rails 3.2.3 In Ubuntu 10.04

Ruby needs to be installed before installing Rails. It is highly recommended that Ruby 1.9.2 or greater is used.

  1. Install Rails as a Ruby Gem – gem install rails -v 3.2.3
  2. Add the following PPA as a package repository – ppa:chris-lea/node.js
  3. Install the required python-software-properties package
  4. Update the package manager
  5. Install the nodejs package
  6. Install sqlite3 package
  7. Install libsqlite3-dev package
  8. Install the sqlite3 gem – gem install sqlite3 -v 1.3.5


Notes


It is highly recommended that the Rails documentation is generated in order to have an offline Rails API reference. Do the following to create the API reference:

  1. In your home directory run this command – rails new sample_app
  2. Navigate to the newly created directory
  3. Run the following command to generate the documentation – rake doc:rails
  4. Move the generated documentation from doc/api to your Documents directory
  5. Rename the moved documentation directory to rails-3.2.3-api-doc
  6. In the rails-3.2.3-api-doc directory create a shortcut to index.html on your desktop, or view index.html in the web browser and bookmark it

27 May 2012

Installing Ruby 1.9.3 In Ubuntu 10.04

Prerequisites for installing Ruby 1.9.3 via RVM are that GIT and Curl is installed.


Installing RVM


  1. Download and run RVM install script - sudo bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
  2. Add all users who need to use Ruby to the RVM group
  3. Logout and login
  4. Update RVM so that the rvm command can be run - rvmsudo rvm get head
  5. Reload the terminal (shell) - source ~/.profile
  6. Test to see if RVM was installed and configured properly - type rvm | head -1
          Terminal should output the following, rvm is a function



Installing Ruby 1.9.3


  1. Install Ruby 1.9.3 – rvm install 1.9.3
  2. Set the default version of Ruby to use to 1.9.3 – rvm use 1.9.3
  3. Test to see if the Ruby interpreter runs with the correct version – ruby -v


Installing OpenSSL And Readline Packages


  1. Install libssl-dev Ubuntu package
  2. Install OpenSSL RVM package - rvm pkg install openssl
  3. Reinstall Ruby with OpenSSL support - rvm reinstall 1.9.3 --with-openssl-dir=$rvm_path/usr
  4. Install libreadline6-dev Ubuntu package
  5. Install Readline RVM package - rvm pkg install readline
  6. Reinstall Ruby with Readline support - rvm reinstall 1.9.3 --with-readline-dir=$rvm_path/usr


Notes


Before starting on the installation of RVM you may need to change a setting in Gnome Terminal if it is used. In Gnome Terminal goto Edit → Profile Preferences. Within the shown dialog select Title and Command tab. Ensure that Run command as login shell is checked.

05 June 2011

Visage Development/Support Survey

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.


15 January 2011

Visage Roadmap

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.

03 January 2011

Other Languages For Web Platform

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.

16 December 2010

Android Support With Visage

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

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

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

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

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

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

21 October 2010

Visage Moving Forward

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

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

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

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

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

01 October 2010

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.

24 September 2010

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!

19 September 2010

JavaFX 1.2 Application Development Cookbook Review

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

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


Relevance

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

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


Presentation

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

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


Content

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


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


Conclusion

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

15 September 2010

JavaFX Improvements

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

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

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

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

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

01 September 2010

JFX Blocks (GUI) 0.3 Released

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

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

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

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