Case Study: GMDSS Simulation

By Helge Fredriksen
Project leader of GMDSS Simulation development
Poseidon Simulation AS
Norway

In this article we will explain a bit of how we successfully employed Excelsior JET in a quite complex application called GMDSS Simulator consisting of a client/server framework connected with an in-house written UDP protocol mechanism.

First, a few words about the purpose and main architecture of the application. A standard Poseidon GMDSS simulator consists of two types of clients bound to a server: students and instructors. As one understands, the software is used in an educational setting, teaching the rules of GMDSS (Global Maritime Distress and Safety System). The instructor creates and maintains a set of training sessions which consists of boats placed on a certain geographical area. Upon connecting to a training session running in the server, the students will have the possibility to operate various maritime radio instruments like VHF, MF-HF and satellite instruments. With these instruments the students can communicate with the other students and the instructors via voice and various messages, the purpose being to train on various maritime distress scenarios.

The product supports both Windows and Linux operating systems.

OC Rosetta

The GUIs are built up using the third party API Qt Jambi. Qt has recently offered Java bindings to the very extensive and highly responsive cross-platform API. This product is called Qt Jambi, and we choose to use it due to the complex instrument graphics in the simulator. Below is seen a sample screenshot of how the instrument view might look like:

OC Rosetta

One of the main concerns when first testing the Excelsior JET was if it were going to handle the JNI bindings which existed in Qt Jambi towards the native Qt libraries. We were amazed to find that this seemed to be out of the box from the product! We had been looking into various obfuscators found on the market, but all of them failed to handle the excessive use of Java Reflection in Jambi.

Upon testing the product we were delighted with the ease of setting up automatic building targets including the Excelsior compile steps. This is achieved since Excelsior provides command line versions of the build tools as well as GUI versions for setting up the projects. When testing the JET-compiled application, just a single discrepancy was found when comparing with the Sun JRE 1.6.0. However, the Excelsior support team swiftly found ways to resolve the issue. All in all our impression of the Excelsior support team can be characterized by the words dedication, skill and responsiveness.

Our goal of using the Excelsior JVM was mainly the excellent protection mechanism it offered to prevent any decompiling of the Java bytecode. Even if using Excelsior meant that deployment had to include the JET Runtime instead of the Sun JRE, we had little overhead in terms of extra installation size.

All in all we are very satisfied with the deployment of Excelsior in our product development. The impression one is left with is a very consistent and professional product.