Ahead of Time Compilation for JavaFX 2.0 applications | e-Zest | India | USA | UK

We at e-Zest are working on JavaFX 2.0 for more than a year and are amongst the few early adopters of the technology. Based on our experience with JavaFX we are evaluating it for a new project we recently received.

The project has the following two requirements for which we need to convert the application to native library using AOT compilation

The application needs to be deployed on Windows, Linux and Mac environments and will be distributed to non-technical users .The users should be able to install the application on a single click. They shouldn’t be required to install the Java and JavaFX runtimes.
The application code needs to be highly secured and users should not be able to view the source code using decompilers.

Packaging JavaFX application as Native

For the first requirement the application doesn’t really need AOT compilation. There are various paid and open source tools available which package the Java and JavaFX runtimes along with the application jars together into a native installer. The user can use the installer to install the application without having to worry about any other software.

We successfully created and tested the installer for a sample JavaFX application on Windows 7 using Install4j . Install4j claims to prepare a similar installer for Linux and Mac OS as well.

Install4j is a paid tool but there are various other open source tools available. More details can be used from the below JavaFX reference link

http://fxexperience.com/2012/03/packaging-javafx-applications-as-native/

Securing JavaFX code:

We cannot use the above tools as Users can easily decompile the source code from the jars packaged with the installers. Although jar obfuscation provides difficulty in reading the source code but a determined hacker can still understand the source.

We evaluated the below tools which support AOT compilation:

Excelsior Jet:

Although Excelsior Jet claims to convert JavaFX 1.2 based applications to native code (http://www.excelsior-usa.com/blog/tag/javafx/) it seems they currently don’t provide support for JavaFX 2.0 based applications.
At the time of writing this blog Excelsior Jet provides support for Java 6 update 26 whereas JavaFX 2.0 needs a higher version of Java.

The tool does convert the application to a native exe but fails to run the application as it’s unable to find the classes specific to higher version of Java. The tool claims to support Java 7 in 3Q of 2012.

Aonix Perc (http://www.atego.com/products/aonix-perc/):

It was difficult to evaluate this tool as an evaluation copy of the tool was not directly available.

After having some conversation with their technical team they informed they currently don’t support JavaFX because it is a technology proprietary to Sun/Oracle (whereas the Java Specification is openly available to the public). While Oracle have announced their intention to also make JavaFX publicly available and part of OpenJDK (which would make it available for inclusion/implementation in PERC), this is not due to happen until at least OpenJDK/Java 8.

Based on the above evaluations we concluded that currently JavaFX 2.0 based applications cannot be converted to native code using AOT compilation.

Dongle based Security

We are currently evaluating using install4j for converting the application into native installer and using dongle based security solution provided by Safenet (http://www.safenet-inc.com/data-protection) for securing the jars. From our initial discussion they claim to secure the code packaged through their tool. I will provide details of our evaluations in my next blog.

Rating: 10.0/10 (1 vote cast)

Pingback: Java desktop links of the week, May 14 | Jonathan Giles
Pingback: JavaFX links of the week, May 14 // JavaFX News, Demos and Insight // FX Experience
rjahn

Securing Code: What about class loaders that supports encrypted class files?
…decrypts class files on-the-fly.

The class files are not readable from decompilers, but you can not win against a professional hacker. If you use public/private keys for encryption, it is harder for a hacker but never 100% save!
Per-Erik Svensson

Why on earth would “native code” be more secure? If you’re thinking assembly code, it is still possible to use a disassembler to get back to assembly and from there a dedicated hacker would still be able to understand the code.

If you defend this by “yes but assembly is harder to understand and you have to understand the specific assembly of the specific hardware which fewer people do so it’s safer” – well then you’re doing “Security through obscurity”. You’re simply betting that no one will understand the code produced by a compiler. Not only is this not true, it is also bad security.

Either AOT is not a solution to your problem OR (which is completely plausible) I’m missing something big here.

Nitin Gupta

I agree native code can also be decompiled and its not a 100% secured process. For our current application we want to make the process as difficult as possible.

Instead of AOT we are now going with a h/w based security solution provided by Sential which will encrypt the contents of the jar file.

Nitin Gupta

As per my recent discussion with technical team at Excelsior Jet they provide support for the Java version required by JavaFX 2.0 based applications . But JavaFX 2.x needs a custom class loader which is currently not supported by Excelsior Jet . Excelsior team plans to provide support for the JavaFX 2.x by end of 2012