Johan's blog

JavaFX Open Source

2010-07-30T15:36:32.635+02:00

I signed the petition to Open Source the JavaFX Platform. I think the benefits of Open Sourcing JavaFX can be huge, both for Oracle and the JavaFX community. The example of Glassfish, where the open community-approach leads to high quality software while still allowing a commercial model, can be followed by JavaFX.

First of all, I should stress that I'm not in a position to dictate what Oracle should or should not do with JavaFX. They inherited the platform through their acquisition of Sun, and they have spent lots of resources in JavaFX. The idea of the petition is rather to convince Oracle that it would be in the best interest of Oracle, the JavaFX developers and the Internet in general to open-source the JavaFX platform.

The ideas behind JavaFX are great: use the power, the maturity and the availability of the Java platform to create a client-side language that allows the rapid creation of highly interactive and rich client applications, that run on all Java-based systems. At this moment, JavaFX is the only RIA platform that is entirely based on the Java platform.
I see a growing interest from Java Enterprise developers in client-side development and vice versa. Without JavaFX, these Java (Enterprise) developers have to choose between a non-Java based RIA or a few thousands specific web-based frameworks for their client development. With JavaFX, it becomes much easier for them to create rich and interactive client-applications.

JavaFX entered the RIA market pretty late. Competition from Flex and Silverlight was already on the market, attracting developers and companies. In order for JavaFX to be successful, time to market is a crucial factor.

The JavaFX platform specification is already pretty ok, but the runtime ports need to be improved. I remember from my first Java-days (in 1995) the problems with lack of Java support on different platforms, and that was exactly the reason I joined the Blackdown team. We had to sign a license with Sun Microsystems, received the source code, and we could work on a port that we could distribute. While this was still a rather closed process, it allowed third party enthusiasts to speed up the availability of Java.

A great example of how open-sourcing a project can enhance its quality and acceptance is Glassfish. The Glassfish project was announced at JavaOne 2005 as the open source Reference Implementation of the Java Enterprise specification. It is a huge project, and Sun and Oracle have spent lots of resources in it. It is difficult to quantify the community input, but there are many people outside Sun/Oracle involved with Glassfish by writing/reviewing code, documentation, working on the Quality Assurance (e.g. via FishCat), working with early access versions etc.
The result of the combination Open-Source with "backed-by-a-company" is in this case a great Application Server, leading edge and still very mature, easy to use and highly configurable.
As a developer, one of the main benefits of the Glassfish community is that I can easily debug issues I run into. If those issues are Glassfish-related, I can report this to the community, I can write a patch myself and commit it to the community. And, very important, while waiting for a released version that contains a fix, I can patch my own version and run my customer projects that require the fix.

I would recommend a similar approach for JavaFX. Strategic and commercial decisions probably belong to Oracle. But opening the Runtime (including ports to mobile and TV) can create a boost in JavaFX quality and enthusiasm. It is important to have a company that is backing the development, and that provides steering and infrastructure. It is also important to have enthusiastic people in the community that are allowed to contribute and to enhance the quality and adoption.

RedFX: connecting JavaFX to the Enterprise

2010-06-10T20:00:43.830+02:00

A couple of months ago, I started to work on RedFX (http://redfx.org), a framework that enables an easy connection between JavaFX client-based code and Java Enterprise based backend code. I strongly believe that the connection between JavaFX and the enterprise in general is an important aspect in the chances of success for JavaFX.

The main reason I started to work on RedFX is that I needed something like this in a number of JavaFX projects I was doing at LodgON. Initially, we were writing lots of boilerplate code for doing REST-calls to a backend, parsing the result via the PullParser, or for synchronizing state between clients and a server.
However, there are some patterns that often come back, and most applications would benefit from a clear separation between the business functionality of the application and the communication and synchronization parts.

The RedFX functionality is partly inspired by the BlazeDS framework from Adobe. RedFX consists of three parts:

(remote) object synchronization: RemoteObjects can be shared across different instances of JavaFX clients and a server.
messaging: JavaFX clients and Java Enterprise server code can publish messages and subscribe to channels
WebServiceClient: make it easier to call remote resources using REST and parse the result into a JavaFX object.

I am currently in the process of open-sourcing RedFX, and integrating it under the JFXtras umbrella. I am pleasantly surprised by the activity on the jfxtras developer mailinglist. The JavaFX - Enterprise connectivity is a very important aspect. The more JavaFX developers are involved with this, the better. Integrating RedFX in JFXtras will enhance the quality, and make it more accessible.

Glassfish 3.0.1 on Amazon EC2: performance and scaling

2010-05-28T10:38:42.159+02:00

Last week, our partner IvoxTools launched 3 voting tests, based on LodgON's DaliCompare software. Performance and scalability were two of the main requirements, and we realized this using a promoted build of Glassfish 3.0.1 and leveraging the Amazon Elastic Cloud Computing (EC2).

With elections for both the Dutch and the Belgian parliament nearing, many people want to know which candidate best matches his own profile. The DaliCompare software allows users to complete a survey and match their answers with the answers of famous people, selected parts of the population (e.g. men, women, people younger than 24 years) and their friends at social network (currently, Facebook, NetLog and Hyves are supported). This allows a funny way for helping people to find out who they have to vote for.

Our partner IvoxTools commercializes this software, and a number of Dutch and Belgian media partners created projects based on DaliCompare:

http://www.depolitiekematchmaker.nl/ (dutch) in the Netherlands
http://stemvanvlaanderen.be/ (dutch) in Belgium
http://lavoixdesbelges.rtlinfo.be/ (french) in Belgium

I'm probably not allowed to give the exact number of visitors, but we are talking more than 6 digits (and counting).
In order to be able to handle millions of users in a short timeframe, the application needs to be performant (responsive) and scalable. For previous DaliCompare projects, we used a high-end dedicated server. The DaliCompare software leverages LodgON's DaliCore framework, which is extremely performant already. Expectations for the current projects were huge, and the expectations were proven to be right. Hence, a single dedicated server for a project would be insufficient during peak moments --- the project URL's were announced several times during prime-time on the major tv stations. The DaliCompare application is written using JavaEE 6. Due to a cookie-bug in Glassfish 3, we decided to use a promoted build of Glassfish 3.0.1. Glassfish, together with a well-written application, guarantees the performance. Scalability is important as well, since the load during peak moments is much higher than the load in off-peak moments. We are using Amazon Elastic Cloud Computing (EC2) to achieve this. This turned out to be very easy, both in configuration and in monitoring.
For each project, we use an Amazon Load Balancer instance with session stickiness, dispatching all requests to a number of instances running DaliCompare and Glassfish. These instances communicate with an instance running mysql for persistence. The architecture of the projects is shown below (click for full-size):

During non-peak moments (e.g. less than 20.000 completed surveys in an hour), the Load Balancer is not needed, and a single instance is sufficient. But it is very easy to create a new instance on the fly (based on an AMI), and add it to the LB --- which is what we do shortly before a major announcement on TV is scheduled.

About the application

DaliCore is the framework created by LodgON that provides granular functionality for social software in general. Basically, it extends the core Application Server functionality with the notion of users, roles, permissions, groups, data, activities, preferences,... . This functionality is needed in most of the projects we do. We have a number of tools that we created on top of DaliCore. The DaliCore is very well tested, both from functional point as from performance point. We use jmeter for testing and regression-testing the performance of DaliCore and are very confident about its behavior.
The DaliCore functionality is made available through REST-API's (implemented using Jersey). Direct EJB-calls are possible as well, but the REST-interface is the one that is extensively tested and we know the performance characteristics very well. DaliCore contains stateless Session Beans and Entity Beans (using JPA).
The DaliCompare application is a WAR, containing the graphical setup and providing the application-specific logic needed for the projects. The real business logic is delegated to the DaliCore application, using REST calls (using the Jersey Client). It may sound strange, DaliCompare is using DaliCore using REST-calls instead of e.g. EJB-calls. We did lots of load testing, though, and Jersey on top of Grizzly behaves extremely well.

The Amazon Load Balancer dispatches requests to the instances that are attached to it. In practice, a single instance is sufficient for most of the time, but failover is a good thing for people's night rest. While completing the survey, some information is kept on the HttpSession. Therefore, it is important that the load balancer selects the same instance for different requests in the same session. This can be easily configured with the Amazon LB.

The DaliCompare and DaliCore applications each have their own http-listener with separate thread-pools. This allows us to fine-tune the size of the pools, both for external calls (to DaliCompare) and internal calls (to DaliCore). The 2 thread pools are also needed, in order to avoid a deadlock. Requests to the DaliCompare often need a request to DaliCore. If there was only a single threadpool, and all these threads were occupied at the same moment by requests to DaliCompare, no request to the DaliCore could be made, hence no requests to DaliCompare could be completed and no threads could be released.

Monitoring is an important part of the DaliCompare operations. The Amazon EC2 console is very useful, it shows the CPU and network load on a per-minute granularity. Apart from that, we monitor the number of threads that are used in every threadpool, in order to optimize CPU usage.

If you want to run an application that needs to handle high volumes or loads, it is very important that you understand how the constituting parts work. Tuning the Application Server can save lots of money. Fortunately, Glassfish allows for a very flexible and transparent tuning.

Map rendering in JavaFX

2010-03-26T13:45:51.817+01:00

Map rendering in JavaFX I have been writing location-based software for a long time. In this area, JavaFX has some nice benefits that allows you to write map-related software easily. As a very simple example, I wrote a map renderer that renders tiles generated by the OpenStreetMap project. The OpenStreetMap project (OSM) is a collaborative effort where map data is provided by different sources and people, and I am very impressed with the quality of the data that is in the OSM database.
Apart from viewing the mapdata at the OpenStreetMap website itself, developers can use the OpenStreetMap API or the Tile Rendering service to integrate OSM based data in their projects.

I wrote a very small JavaFX project that retrieve tiles from the Tiles@home rendering project and shows them. This project is far from a functional mapping project, but it shows how easy it is to move around on a map and to zoom in or zoom out using JavaFX.
http://javafx.lodgon.com/osmtile/TileClient.jnlp will start the map renderer.

I made the code for this project available as well:

The code is pretty simple and self-explaining, so I am not diving too deep into it here. The one thing I want to point out, is how easy it is to show a scaled image while transferring the zoomed images.
If you zoom into a specific area, the application will first show the existing tiles in a scaled way, while downloading the new tiles. Downloading the new, more detailed tiles, can take some time and the user needs to view "something" while waiting. We solve this by scaling the tile from the lower zoom level, and showing this until the needed tiles are downloaded.
Each TileUI instance represents a tile, and contains a reference to its "zoomParent", which is the tile at the lower zoomlevel that covers this tile. It also contains a list of tiles at the next zoomlevel that are covering the same area as this tiles. When a new tile is requested, its parent tile is looked up and the new tile is added to the list of "covering" tiles for this parent:

100             if (tileMap.containsKey(pidx)) {                          
101               var ptile: TileUI = tileMap.get(pidx) as TileUI;                                                                                                           
102               insert newtile into ptile.covering;                                                                                           
103               newtile.zoomParent = ptile;                                                      
104            }

Once all tiles for the new zoom level are downloaded, the scaled tile at the lower zoom level should not be visible anymore. This is accomplished by removing the dowloaded tile from the list of covering tiles

30   var image: Image = Image {
31       url: resource;
32       backgroundLoading: true;
33     }
...
35   var loading = bind image.progress on replace {
36     if (loading ==100) {
37       delete this from zoomParent.covering;
38     }
39   }

and by only showing a tile when its zoomlevel is the active zoomlevel or when this tile is covering higher-zoom tiles:

47   override var visible =  bind ((zoom == mapView.zoom) or (sizeof covering > 0) );

I like the simplicity of JavaFX. I should stress though, that this application is not a production-ready application. Ideally, we need to remove tiles from the cache to save memory, and many other things should be improved as well. But the goal was to show how easy it is to write a tile renderer in JavaFX.

Using Glassfish Embedded in offline mode

2010-02-07T10:46:17.903+01:00

I have been using Glassfish Embedded (or is it Embedded Glassfish) in a customer project recently. At first, I just considered it as a customer project, but now that I think about it, the concept of Glassfish Embedded opens lots of possibilities.

Unfortunately, I am not allowed to talk about this specific project and what kind of application it is. But the reason for using Embedded Glassfish is clear. We created an Enterprise Application for this customer in the past. The customer is happy with it and uses the application inside the company and with a few other customers.
Then, the customer receives questions from his own customers that could be addressed with the Enterprise Application. We are talking about a big customer here, and big customers have typically meetings with big companies in large meeting rooms without public Internet access.
Also, many presales people are afraid of giving live demonstrations over the Internet and prefer their own laptop. In many cases they show a PowerPoint presentation, but the number of potential customers who can be convinced with slideware is decreasing.

And here is a perfect opportunity for Glassfish Embedded. It can be preinstalled and configured on a demo laptop, and (pre)sales people can show exactly the functionality that would be available in a full-blown Internet-enabled application. They have everything under control, no server that might go down, no dependency on a guest-account on a semi-private Internet, no interference with other people using the application at the same moment,...

It may sound strange to some to demonstrate a complex Enterprise Application on a simple laptop (and laptops of (pre)sales people are often great in design and pathetic in performance), but with Glassfish Embedded it is possible:

* laptops have much more power than some years ago, even the build-for-design laptops
* The performance of Glassfish is great.
* Glassfish is easy to use and to configure.
* The footprint of glassfish is small. All Java EE functionality is implemented, still the embedded jar is below 50 MB. That is probably the size of 2 power point presentations on a (pre)sales laptop.
* Complex problems often require simple solutions.

This example is just one usecase where Glassfish Embedded can make life easier. There are probably lots of others as well.

For more information about Glassfish Embedded, see the following links:

https://embedded-glassfish.dev.java.net, the official home
http://blogs.sun.com/alexismp/entry/glassfish_embedded_reloaded, an overview + hello world app from Alexis
http://docs.sun.com/app/docs/doc/821-1208?l=en, the official guide.

JavaFX chat application for focus groups

2010-01-22T15:56:00.439+01:00

Over the last months, we have worked on an application that allows companies and organizations to chat with a dedicated focus group in a controlled environment. We already have some users for this, e.g. a marketing company that wants to get the first impressions from users on a new campaign. The chat client is written in JavaFX and the backend runs on Glassfish v3 with Comet support enabled.

I have written some blog entries about JavaFX chat code before. The principles in these entries are also used in the iParticipate application --- iParticipate is the commercial name of the application, I think. The iParticipate application is focused on moderated chats, though, allowing a moderator to review, delay, accept or reject messages before they are shown to the other users. The setup is hence slightly more complicated, but you can try it yourself at http://g6.lodgon.com/TalkingBe.

We have 2 different views on the application: an administrator view and a user view. The user view is pretty simple and shows a chat window, an overview of participants, and a whiteboard:

The administrator view is based on the same code, but we have some more panels here:

The moderator has some more options:

add pictures and movies to the sessions and show them (full-screen or not)
moderate incoming chat messages: accept them, reject them, or put them in a queue
manage the auto-approve option by setting moderation time
send a private message to a user
manage bookmarked messages
...

Actually, there are a lot more options, but they should be described somewhere else.

Going back to the code and architecture, this project is a nice combination of Glassfish v3 and JavaFX. The backend is a Java EE 6 WAR application, containing REST handlers (using Jersey), session beans and JPA Entity Beans. Different projects can be created simultaneously, and messages for one project are of course separated from the other projects. Actions (writing text, bookmarking messages, confirming messages,...) are implemented as REST calls, and each client has a Comet Handler.

The JavaFX client code uses the HttpRequest for sending all request actions, and the incoming messages are retrieved using the asynchronous JavaTaskBase/RunnableFuture constructions. See http://blogs.lodgon.com/johan/JavaFX_chat_client_with_Comet_server for some basic code.
Animations are used for dealing with the auto-approval functionality (if the moderator does not do anything during a configurable amount of seconds, a message will be automatically approved).
The media packages are used for showing media content. The administrator manages when and how media content is shown to the user.

The iParticipate application shows that you can do lots of things with JavaFX that are extremely difficult to achieve in HTML. Once again, this convinces me that HTML is not the way forward for application development.

GlassFish v3 release

2009-12-10T15:16:45.018+01:00

A few minutes ago, GlassFish v3was released. When I first talked about GlassFish v3 in this blog entry, I considered it a revolution rather than an evolution. Today, I still believe GlassFish v3 is more than just the numerical successor to GlassFish v2.

Reference implementation

First of all, GlassFishv3 is the reference implementation of the Java EE 6 specification. Compared with Java EE 5, this specification is a next step towards simplification in enterprise development. The voice of the enterprise developers has been heard. Personally, I am very happy with the JSR 311 (Java API for RESTful Web Services) and the EJB 3.1 spec. One of the major benefits of JSR 311 is that it facilitates mobile applications instead of just Web Applications. A decoupling of business logic and front-end development at the REST interface offers lots of possibilities.

It took awhile before I realized the real benefits of EJB 3.1. But once I started using a NetBeans 6.8 milestone, it became clear that the enhancements are significant. We don't have to package an ejb-jar and a war together in an ear anymore, everything can be in one package (with the confusing name "war", though).

Open Source

GlassFish v3 is completely Open Source. I have the head-version of the repository on my desktop, and it is not too difficult to build and install it yourself.
The simple fact that software is Open Source itself does not say anything about its quality. But in the GlassFish case, the code is very well written and documented, and I was often surprised how easy it is to dive into the code of this complex piece of software.
Having access and being able to understand the source code is something that speeds up development. In a number of cases, your application is not behaving the way you want it, and you assume that this is a bug or some strange feature in the application server. You can spend lots of time trying to find out the cause without looking into the application server --- and that is how it goes most often. But you can also look into the relevant code of the Application Server and try to find out what is causing the problem. When the code is available and readable, this process can save developers time.

Modular

One of the major changes in GlassFish v3 is the modular approach. The old lib-directory has been replaced by a modules directory. Modules can be installed and uninstalled easily. The Glassfish kernel itself is very small. As a consequence, the kernel itself is also usable in environments with limited resources -- desktop and even mobile. Today, most modules are still enterprise focussed, but the GlassFish modularity can be a next step towards convergence between enterprise and mobile software. Enterprise software is becoming simpler, and mobile devices are becoming more powerful. Software patterns and technologies that are typically used in one environment may also work (or be adapted) in another environment.

I assume GlassFish v3 will be primarily used in the same areas where GlassFish v2 and other Application Servers are used. But in the future, I think GlassFish can extend its marketing potential into new areas, especially when modularity is required and when resources are still somehow limited, preventing typical big application servers from being used.

JavaFX and OSGi, part 2

2009-11-24T20:32:47.668+01:00

In my previous blog entry, I described a method to execute an OSGi framework in a JavaFX runtime. In this entry, I show how you can write OSGi Bundles containing JavaFX code, and how they can be installed into the OSGi platform running in the JavaFX runtime.

The idea behind this code might be a bit strange and dumb (why would one want to write an OSGi bundle containing JavaFX and deploy it in an OSGi container on top of JavaFX?) but I have two reasons why this is really a practical use case.
In the hopefully not too distant future, we might have more devices that come with JavaFX preinstalled. My HTC Diamond phone, for example, has a JavaFX platform. If I want to install an OSGi framework onto this phone, it has to run on top of the JavaFX platform.
Also, more developers are getting used with OSGi. The JavaFX platform provides interesting front-end capabilities for OSGi based services. With JavaFX, front-end development is in general much easier than with any (A)WT framework I know.

The OsgiFX framework

Running an OSGi framework on top of JavaFX is described in this blogentry, and the code can be found at http://code.google.com/p/osgifx. Note that I made some major changes to the code since I wrote the previous blog entry --- I hope to find some time to discuss those in a next entry.

When starting the OSGiFX application, an OSGi Framework is created (I use the Knopflerfish framework), and an org.osgifx.FxServiceListener instance is registered, listening for implementations of org.osgifx.view.JavaFxView
This interface acts as a bridge between the registered OSGi services and the OSGiFX application that will manage and display the services. JavaFxView is a plain Java Interface, with two methods:

getTitle() provides the title of the registered application
getRootNode() provides a javafx node that is the container for all ui-stuff in the application.

The OSGiFX application maintains a list of registered JavaFxView implementations, and will display an application when the user clicks on a name --- yes, it is sort of a Service Browser on top of OSGi.

Applications

I wrote a silly OSGi bundle that registers a JavaFXView implementation containing a JavaFX custom node with a nice circle.
You can find the code and manifest file at http://lodgon.com/johan/javafxbundle.tar Again, I hope to find more time later to document this better, but I think the code in the BundleActivator is self-explaining:

  override function start (bc: BundleContext) {
    println ("[JVDBG] Starting bundledemoactivator");
    var view: MyView = MyView{};
    var impl: JavaFxViewImpl = new JavaFxViewImpl (view);
    var props :Dictionary= new Properties();
    bc.registerService(JavaFxView.class.getName(),impl,props);
  }

The MyView class contains a CustomNode with the circle, and the JavaFxViewImpl class will return this CustomNode when its getRootNode() method is called.

When bundling this code into an OSGi bundle, we have to make sure we import the needed packages. The JavaFX compiler creates some dependencies on implementation packages, these should be exported by the OSGiFX platform and imported by the bundles that rely on them.

This was a very quick intro to what I have been doing with OSGi and JavaFX, feel free to mail me if you have questions or remarks (johan at lodgon dot com).

JavaFX and OSGi, part 1

2009-10-05T20:21:44.829+02:00

Integrating new technologies is something that I like. The combination of JavaFX RIA technology and the OSGi platform was on my wish-list for some time. The title of this entry contains "part 1" since I assume this is an ongoing effort. When combining JavaFX and OSGi, a number of possibilities exist:

Install a bundle containing JavaFX code in an OSGi framework
Run an OSGi framework in a JavaFX environment

The first option is described in this blogentry.
The second option is very relevant to me, since I hope that there will be a huge number of devices that come pre-installed with JavaFX. If the OSGi lifecycle management platform runs on these devices, lots of nice stuff can be executed on the devices.

The latest OSGi specification contains a framework launch API. This allows the framework to be instantiated by third party code. This is cool, since it allows me to start an OSGi framework without any code change to the framework implementation code.

For my proof of concept, I use the KnopflerFish framework from Makewave. This is an Open Source implementation of the OSGi specification, and it is very readable.
Running the Knopflerfish framework in JavaFX is not too difficult. You have to be careful with the threading system of JavaFX though ("don't block the AWT thread", remember?). I did it this way:

The Main.fx class launches the Framework and obtains a reference to the System Bundle, hence to a BundleContext Object
The BundleContext is used for installing new Bundles and for registering a ServiceListener and a BundleListener. Installing Bundles is done asynchronously, not in the UI thread.
A JavaFX class implements BundleListener and ServiceListener is notified on Bundle and Service Events, and some UI component the Main.fx class reflects the changes.

This approach leads to 4 classes:

Main.fx
BundleInstaller.fx contains the FX code for installing bundles
NativeInstaller.java contains the Java code for installing bundles
FxServiceListener.fx implements both ServiceListener and BundleListener

Here is the code:

package com.lodgon.kfix;

import org.osgi.framework.launch.Framework;
import org.osgi.framework.launch.FrameworkFactory;
import org.osgi.framework.BundleContext;
import org.osgi.framework.Bundle;
import java.util.HashMap;
import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.control.TextBox;
import javafx.scene.control.Button;
import javafx.scene.Group;
import javafx.scene.layout.VBox;
import javafx.scene.control.Label;
import javafx.async.Task;

/**
 * @author johan
 */

var urlText: TextBox = TextBox {
    text: "http://xavier.lodgon.com/osgi/log_all-2.0.0.jar"
    width: 282
    selectOnFocus: true
  }

  var installButton: Button = Button {
    translateX: 300;
      text: "install"
      action: function() {
        var installer: BundleInstaller = BundleInstaller {
          bc:bc;
          location:urlText.text;
        }
        installer.start();
      }
    }

  var installGroup: Group = Group {
    translateY:10;
    content: [urlText, installButton];
  }


  public var eventListBox: VBox = VBox {
    translateY:50;
  };



var stage: Stage = Stage {
    title: "Application title"
    width: 450
    height: 180
    scene: Scene {
        content: bind [
            installGroup,
            eventListBox
        ]
    }
  }

var bc: BundleContext;
var listener: FxServiceListener ;

function run () {
  stage;
  var knopflerfish: org.knopflerfish.framework.Main =
  new org.knopflerfish.framework.Main();
  var factory:FrameworkFactory = knopflerfish.getFrameworkFactory();
  var map:HashMap = new HashMap();
  var framework: Framework = factory.newFramework(map);
  framework.init();
  listener = FxServiceListener{};
  bc = framework.getBundleContext();
  bc.addServiceListener (listener);
  bc.addBundleListener (listener);
}

BundleInstaller:
package com.lodgon.kfix;

import javafx.async.JavaTaskBase;

import javafx.async.RunnableFuture;
import org.osgi.framework.BundleContext;

/**
 * @author johan
 */

public class BundleInstaller extends JavaTaskBase {

  public-init var bc: BundleContext;
  public-init var location: String;
  var installer: NativeInstaller;

  override protected function create() : RunnableFuture {
    installer = new NativeInstaller(bc, location);
    return installer;
 }

}
NativeInstaller:

package com.lodgon.kfix;

import javafx.async.RunnableFuture;
import org.osgi.framework.BundleContext;

/**
 *
 * @author johan
 */
public class NativeInstaller implements RunnableFuture {
  private final String location;
  private final BundleContext bc;

  public NativeInstaller (BundleContext bc, String loc) {
    this.bc = bc;
    this.location = loc;
  }

  @Override
  public void run() throws Exception {
    System.out.println ("[JVDBG] I have to install bundle at "+location);
    bc.installBundle(location);
    System.out.println ("[JVDBG] I installed "+location);
  }

}

FxServiceListener:
package com.lodgon.kfix;

import org.osgi.framework.*;
import javafx.scene.control.Label;

/**
 * @author johan
 */
public class FxServiceListener extends ServiceListener, BundleListener {

  override function serviceChanged (evt: ServiceEvent) {
    println ("[KFiX] Service changed: {evt}");
    var label: Label = Label {
        text: "service changed: {evt}"
      }
   insert label into Main.eventListBox.content;
  }

  override function bundleChanged (evt: BundleEvent) {
    println ("[KFiX] Bundle changed: {evt}");
    var label: Label = Label {
        text: "bundle changed: {evt}"
      }
    insert label into Main.eventListBox.content;
  }


}

That's it for now, but I have more ideas...

JavaFX location example with GPS

2009-09-26T14:09:21.128+02:00

One of the cool things about the JavaFX Mobile platform running on my HTC Diamond phone, is the easy integration with GPS. In this article, I will describe the most simple example I could come up with.

I have been working with GPS integration in Java code since more than 10 years now. In most cases, I had to use the serial io provided in comm.jar implementations (the one providing javax.comm.SerialPort and others). Although this worked fine in most of the cases, the amount of low-level code was high compared with the amount of functional code.
I have been a big supporter of JSR 179, the Location API for J2ME. This API provides a simple way for obtaining locations and it also provides some common functionality (e.g. proximity listeners). Until recently, I haven't seen much devices that contained a clean implementation of this API. But this is changing.

The JavaFX Mobile 1.2 for Windows Mobile platform contains an implementation of JSR 179, and it works very well with JavaFX.
The following code example shows a simple JavaFX example showing the status of the built-in GPS and the latest known position. It probably violates some patterns, but the only goal is showing how you can obtain position in your JavaFX programs.

The main class

The main class is a typical JavaFX example containing a Stage with a Scene. The Scene contains 2 Text items. The contents of these text items are dynamically bound to some variables.

package com.lodgon.locationdemo;

import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.text.Text;
import javafx.scene.text.Font;

public var gpsStatus: String = "unknown";
public var lat: Number = 0.0;
public var lon: Number = 0.0;

var stage: Stage = Stage {
    title: "Location demo"
    width: 250
    height: 120
    scene: Scene {
        content: [
            Text {
                font : Font { size : 16 }
                x: 10
                y: 30
                content: bind "gps status: {gpsStatus}"
            },
            Text {
                font : Font { size : 16 }
                x: 10
                y: 50
                content: bind "position: {lat}, {lon}"
            }
        ]
    }
}

function run () {
  stage;
  var processor: LocationProcessor = LocationProcessor{};
  processor.startReading();
}

No magic in here, notice the LocationProcessor class that we instantiate and that will do the interaction with the GPS. This instance will create a javax.microedition.location.LocationProvider and register a javax.microedition.location.LocationListener with it.

When the status of the GPS is changed, the providerStateChanged method is called. The new status is assigned to the gpsStatus variable in the Main class and shown on the device screen.
Similarly, when a new position is detected, the locationUpdate method is called, and the lat and lon variables in the Main class are changed.

package com.lodgon.locationdemo;
import javax.microedition.location.LocationListener;
import javax.microedition.location.Location;
import javax.microedition.location.LocationProvider;
import javax.microedition.location.QualifiedCoordinates;

public class LocationProcessor extends LocationListener  {

  var provider: LocationProvider;

  public function startReading() {
    provider = LocationProvider.getInstance(null);
    provider.setLocationListener(this, 10, 5, -1);
    providerStateChanged (provider, provider.getState());
  }

  override function locationUpdated(provider: LocationProvider, location: Location) {
    if (location != null) {
      var coords: QualifiedCoordinates = location.getQualifiedCoordinates();
      if (coords != null) {
        var lat = coords.getLatitude();
        var lon = coords.getLongitude();
        println ("[JVDBG] lat = {lat}");
        Main.lat = lat;
        Main.lon = lon;
      }
    }

  }

  override function providerStateChanged(provider: LocationProvider, stat: Integer) {
    if (stat == 1) {
      Main.gpsStatus = "Available";
    }
    if (stat == 2) {
      Main.gpsStatus = "Temporarily Unvailable";
    }
    if (stat == 3) {
      Main.gpsStatus = "Out Of Service";
    }
  }

}

For more information about JSR 179, see the Javadoc pages. You can easily change the update frequency (currently 10 seconds), timeout (currently 5 seconds), and other criteria. Also note that we actually should not do any processing in the interface callback methods. Since this is a simple example without much processing, I didn't use the javafx async threading mechanism for simplicity.

Social Networking in Telematics

2009-09-25T11:08:46.597+02:00

I'm on my way back from the ITS 2009 world conference in Stockholm --- see the website of the World Contress and Exhibition on Intelligent Transport Systems and Services for more information about this conference. We were showcasing an application that combines social networking with vehicle telematics. The past few days were really exhausting, but it definitely was worth it.

Our company LodgON was selected as one of the four finalists of the CVIS Application Contest. CVIS is a project funded by the European Commission. In this project, a global architecture is defined that allows the creation of cooperative vehicle applications. Developers use the Service Development Kit, based on the OSGi software of MakeWave and create their own applications.

The four finalists developed different applications, ranging from pedestrian safety over intelligent agents to the social networking application that we developed. Visitors of the CVIS booth could vote for one of the finalists. We won the silver prize, worth 15.000 EUR. I am happy because we won this prize, and I am unhappy since we didn't win the gold prize (25.000 EUR).

For LodgON, this conference was also very important since we demonstrated our Dali-based vehicle social networking application. You can find more information about this application at our website. We have a strong background in Social Networking, and most of the LodgON employees also have a background in Telematics. This combination automatically leads to a Social Networking application for telematics. My main question, though, was if the automotive industry was ready for this kind of applications. I am extremely pleasant surprised that indeed there was a huge interest from conference visitors in our application. Road authorities, car OEM's, telecom operators, consumer organisations,... they all showed a clear interest in Social Networking, and they definitely do realize the benefits of social networking if it is properly implemented.

With our Social CVIS application, we showed that the research and development we have done during the past years in the field of social networking is really rewarding. We know the ins and outs, the benefits and pittfalls. We realize the importance of social status, we balance between clarity and fine-grained permission models. Social networking is more than having an account on facebook. The return on investment can be huge, but your project can also fail completely if you don't combine users expectations with the goals of the company/organisation that is behind the project.
We will have some work in the coming weeks, with the follow-up of the new contacts we have (and the re-connection with some old friends). But there are lots of opportunities out there now.

From a technical point of view (and in the end, that is what I am mostly involved with), this project has been fun as well. We combined our experience with OSGi, Glassfish and JavaFX in order to create the prototype. Glassfish is really mature, and more than ready for production. We already knew this, but it's proven once again. The ease of development and the clear way of operations is worth a lot. The Jersey bundle in Glassfish (yes, we talk bundles since we use Glassfish v3) is one of my favourites, it allows an uncoupled REST-based client-server approach.
We showed 4 clients for our application, one of them being a JavaFX mobile client, using GPS data through JSR 179. I have been working with GPS data often, and in most cases it came down to using the serial COMM port and talking to native GPS drivers. Which is fun for a while. I was extremely happy and positively surprised when I discovered that JavaFX supports JSR 179, and it takes about 10 lines of code in order to read the exact position from my HTC Diamond phone. This is one of the reasons I believe in JavaFX: easy support for real devices.

The telematics, location based social networking server is based on our Dali Community Server. We announced our Dali Roadmap last week as well, and the positive feedback we got about this application proved to me that we made the right decisions in the development of Dali.

JavaFX chat client with Comet server

2009-09-14T12:23:30.738+02:00

I have written a few entries about a JavaFX chat client and about a Comet Chat engine. Now, I have put together the simplest examples I could come up with.

Both the ChatServer (using Comet) and the ChatClient (in JavaFX) can be downloaded here.
Some remarks:

Comet based ChatServer

The ChatServer directory contains a Netbeans project that uses Comet in GlassFish v2. If you want to run this example in GlassFish v3, you have to change the package name

 com.sun.enterprise.web.connector.grizzly.comet;  into  com.sun.grizzly.comet.CometContext .  The ChatServer contains 3 classes:

ChatEntry

This is a POJO, containing the information about chat entries (only a username and a text are used).

ChatServlet

This is the entry point for clients. Comet initialization is done in the init(ServletConfig config) method. Incoming requests have a parameter method. This parameter can have two values: listen and chat.

listen

A new CometHandler is created, and the PrintWriter of the HttpServletResponse is attached to the CometContext When new chat entries are received, the CometHandler will send the content to the attached writer.

chat

An incoming chat entry is received. The CometContext is notified about this event, and it will send the chat text to all registered listeners.

ChatHandler

This is our implementation of the CometHandler. When a client starts listening, a new instance of the

ChatHandler is created, and the PrintWriter connected to the ServletResponse is stored. When new chat entries are received, the onEvent method will be called, and the chat text will be written to the PrintWriter instance.

JavaFX ChatClient

The ChatClient is slightly more complicated. See one of my previous blog entries for a detailed description of a JavaFX chat client. The example described in today's entry is simplified a bit. We don't use a separate class for writing new chat entries, but we use the HttpRequest for calling a url containing the chat entry information. We can't use the same approach for reading incoming chat entries, since the onInput function of the HttpRequest is only called when all input has been read. The existing javafx.data packages are very suitable for reading message-based content (i.e. RSS feeds), but not for streaming. Hence, we created a mechanism where a callback interface (ChatInput is called each time the InputStream receives a new chat entry). This is done by means of the FXReader JavaFX class and the AsyncReader java class. Again, for implementation details have a look at my previous blog entry.

At LodgON, we are working on a product that contains chat functionality. It is more complex than the example we've shown here, i.e. the chat can be moderated, users can have different roles, documents can be shown,... . The basic principles of the chat interactions are the same, though.

Data accuracy, a killer app?

2009-08-27T22:21:03.404+02:00

I am one of the 992.653 (and counting) followers of Tim O'Reilly's twitter. O'Reilly tweets very often about "cool stuff". That makes it hard for me to distinguish the real cool stuff from the "nice tries". But one tweet about "the killer app for Apps for America" took my attention. It is about data integrity for government data.

The article O'Reilly is referring to can be found at the Sunlight Labs blog. The bottom line is that the accuracy of (government) data is extremely important and is often beyond developer scope. The article lists three ways to improve data accuracy:

1.Make Data Imports Modular and Reusable

2.Create tests on the regulations around the data

3.Provide a way for users to report inaccuracies

The first and second way are pretty well known in software development -- although often being ignored in government projects I am aware off, because the requirements in government projects are mostly non-technical.
The third way is still rare, although we see a growing interest in this concept. Allowing people to report inaccuracies is often hard, since this basically means that you admit that you might be wrong. And this is something that many customers/organizations still don't want to hear. However, the benefits of using the community to improve the quality of data are huge --- depending on the nature of your community and data of course. Especially when large amounts of public data are the core of a project, it definitely helps to let the user report about the data quality. This goes further than reporting "inaccuracies" though, users can also indicate their importance or appreciation about particular data.

An interesting example is data related to road and street conditions. At least in the country where I live in, government bodies are responsible for keeping road signs visible, making sure there are no dangerous road conditions and so on. But this requires intensive checks from a number of people. A missing sign will probably be spot by hundreds of people before it is seen by the government body.
It would be easier and cheaper if one of the hundreds of people that saw the defect earlier reports this problem online or via an in-car device, PDA or mobile phone. If this is where the software stops, the data quality is unlikely to improve. There will be quite a lot of funny people that will report unmissing stuff as missing. We would use strong authentication and written agreements about punishment for fake reports, but this will scare many people. In many cases, the community can regulate itself. Good citizens will be recognized and rewarded, bad behavior will be filtered as spam. I recently reviewed the book Algorithms of the Intelligent Web, and this contains a number of technologies that can be used to improve the quality of data based on user behavior and algorithms.
Apart from the algorithms, there is a social aspect. In communities, users want to be recognized and appreciated. An implicit or explicit "ranking" amongst users can motivate them to be "good citizens". Good behavior is rewarded by an increase in ranking, bad behavior cause a drop in ranking.

My conclusion is that the quality of data can often be improved by software, a dramatic improved comes from the right combination of community software and human community development.

Development and source code

2009-08-13T21:30:26.857+02:00

A quick one. Some people think that I use the latest version of software just for fun. Not. Well, it is fun of course, but it speeds up my development considerably. Read on for an example.

I am developing some OSGi/JavaEE code under GlassFish v3. When starting a bundle, "it didn't work", During development, I *always* have the server.log file open (tail -f /opt/glassfish/glassfish/domains/domain1/logs/server.log should be under F1). I saw this error:

[#|2009-08-13T21:16:06.549+0200|SEVERE|glassfish|org.apache.catalina.loader.WebappLoader|_ThreadID=19;_ThreadName=Thread-2;|LifecycleException
java.lang.NullPointerException
        at java.util.StringTokenizer.<init>(StringTokenizer.java:182)
        at java.util.StringTokenizer.<init>(StringTokenizer.java:204)
        at org.glassfish.web.osgi.OSGiDeploymentContextImpl$2.convert(OSGiDeploymentContextImpl.java:153)
        at org.glassfish.web.osgi.OSGiDeploymentContextImpl$2.getURLs(OSGiDeploymentContextImpl.java:147)
        at org.apache.catalina.loader.WebappLoader.setClassPath(WebappLoader.java:1204)
        at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:736)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:5187)
        at com.sun.enterprise.web.WebModule.start(WebModule.java:509)

Ok, so what do you do when you have this? I can only think about one possibility:

cd glassfish/svn/v3

find . -name OSGiDeploymentContextImpl.java

Aha, there is the file. Open it. (with vi, can be NetBeans too though). Look at line 153, and there it is:

StringTokenizer entries = new StringTokenizer(bcp, ",;");

Where bcp is a String that is passed with the value of Constants.BUNDLE_CLASSPATH

Whoops, looking at my manifest-file, and indeed, I supplied "Bundle-Classpath" instead of "Bundle-ClassPath",

Took me less than 5 minutes to discover, fix and redeploy. How can you do this if you don't have the source code of the tool/appserver you're using?

Is it a Module or a Bundle? Both, in GlassFish v3

2009-08-12T14:15:20.533+02:00

With GlassFish v3, developers can deploy their software as traditional modules (jars and wars), but also as OSGi Bundles. Even more: one jar can be a Web Archive and an OSGi Bundle at the same time. It reminds me of the question whether light is a particle or a wave phenomena. It is both, depending on how you look at it.

I blogged about this more than a year ago. GlassFish v3 is not just an evolution, it is a revolutionary concept. Of course, it is also the reference implementation for the Java Enterprise specification, so it does not break the good tradition of GlassFish v2 by providing a first class Java EE compliant Application Server.
But you can also deploy OSGi bundles in GlassFish v3 (you should download the latest promoted build if possible, since this technology is evolving rapidly). And that opens new possibilities --- including some cans of worms, more possibilities lead to more opportunities to screw up. This blogentry by Sahoo is a good starting point to experiment with the dual behavior of applications in GlassFish v3. Sahoo uses the term "hybrid application" for an application that both uses Java EE and OSGi. I also recommend reading Jerome's blog. He provides some examples about using OSGi Declarative Services in GlassFish v3.

There are some distinctions and some minor overlaps between the OSGi goals and the Java EE goals. OSGi provides the modularity and the lifecycle management where the Java Enterprise specifications provide the traditional enterprise functionalities as persistence, transaction support, resource management.
The mental coin flipping that is happening inside my developer head is whether my applications are now OSGi applications that leverage the Java Enterprise functionality, or are they Java Enterprise applications that benefit from the OSGi modular system? The combined functionality of both worlds offers lots of opportunities, but will also give birth to new patterns, do's and dont's. These are exciting times.