Video: Nikita Lipsky Talks About Java AOT Compilation @JavaZone 2016

Our very own Nikita Lipsky, one of the “fathers” of the Excelsior JET project, was at the JavaZone conference in Oslo last week to give a talk about Java AOT compilation. Here are the video and slides of his talk:

Categories: Java, News

Tags: , , , , ,

Techsupport Fairy Tales: Main Thread Lives Two Lives

A number of old tests get a new life every time we add support for another target architecture or platform. Here comes a fresh record from our labs:




Popular free desktop Java Swing app that has been part of the Excelsior JET test suite for many years.


Clicking the right mouse button on the application’s tools panel results in:

  • expected behavior on Apple Java SE 6

  • NoClassDefFoundError on Oracle HotSpot 1.7.0_55, thrown because the class apple.laf.AquaPopupMenuUI is absent in the Oracle JRE for OS X. The application catches it and displays a dialog inviting the user to try the latest version or report the problem.

The latter is what we expected the natively compiled application to do, because the Excelsior JET Runtime includes exactly the same classes as the respective version of the Oracle JRE for the same platform.

However, the app did not show that dialog if natively built. Launched from a terminal, it would dump the call stack to that terminal, but without a terminal it appeared to the user that some functionality has been silently disabled for no apparent reason.


The execution paths diverge in the code that handles the initial NoClassDefFoundError: in the native build, that code itself throws a NullPointerException, effectively canceling the creation of the error dialog.

Here is a small excerpt:

Thread[] ts = new Thread[Thread.activeCount()];

As you might have guessed, code that follows iterates over the ts array, assuming that it has been filled with references to all active threads. Indeed, on HotSpot the entire array is full of valid references to Thread instances. But in the native build, the last element of the array appears to be null, and the absence of a guard against that leads to an NPE.

It is easy to reproduce this problem on a small sample by having the above code executed from SwingUtilities.invokeLater().


Fact is, activeCount() returns the number of all threads, both alive and dead, whereas enumerate() only goes over the threads for which isAlive() returns true. So in the general case, one must check for null references when iterating over an array filled returned by Thread.enumerate().

But why does the app work on HotSpot, whereas the native build fails? Here one subtle difference between the two implementations of the JVM specification comes into play:

Upon termination of the main thread, the HotSpot VM "reincarnates" it as a new, DestroyJavaVM()-thread, which waits for all other threads to terminate. (Actually, those two are the same thread, but from the JVM’s point of view they are different, hence me quoting the word "reincarnates".)

In the Excelsior JET Runtime, however, the main thread is marked as dead upon termination, and then "waits" for other threads to die. As a result, when called after the termination of the main thread, activeCount() returns a number that is greater than the number of threads that a subsequent call of enumerate() would, well, enumerate, greater by at least one.


We could possibly change the Excelsior JET Runtime so that it behaves identically with HotSpot in the above scenario. However, the specification does not guarantee that the result of an activeCount() call is at all times equal to the length of the array that a subsequent call of enumerate() would fill. In fact, that cannot be guaranteed in the presence of dead threads, so the said code only works on HotSpot if there are none yet. A close inspection of Thread.activeCount javadoc would confirm that:

Returns an estimate of the number of active threads…

Therefore, the code of the application is incorrect both with respect to the Java specification — it relies on the behavior of a specific implementation, HotSpot, and in general — checking for null array elements would have prevented the problem.

Verdict: no treatment necessary (on our side, anyway).

Categories: Excelsior JET, Java

Tags: , , ,

Weekend Fun: Help Robotality Beta Test a Native Build of Their Desktop Java Game

Halfway is a futuristic turn-based strategy RPG from Robotality. It is written in Java using libGDX and is available for Windows, OS X, and Linux.

If you are into this kind of gaming, Robotality just published native builds of Halfway in the beta section, so you can give Halfway a shot for free before heading over to Steam to buy it. (Update: It turns out betas are only available to those who bought the game. Sorry.) We would greatly appreciate your feedback, because, as you may have guessed, those native builds were done with Excelsior JET:

Using JET to compile a native version has been enjoyably straightforward. Once set up, creating a build is a matter of pointing it to the game code & assets, and have it spit out an archive or installer with a native executable a few minutes later.

— Daniel Ludwig, Robotality

Happy gaming!

Categories: Customer Showcase

Tags: , , ,

An Unorthodox “Solution” to an NPE Puzzle

I’ve been subscribed to Java Performance Tuning by Jack Shirazi and Kirk Pepperdine forever (compared to other e-newsletters), not least because of the introductory pieces. Jack opened the Feb 2014 issue with a small puzzle stemming from a real problem his colleague encountered. I forwarded it to our developers immediately:

This month I’ve got a little puzzle for you. How can you get a null pointer exception from the following piece of code?

    //map is an instance of HashMap
    x = map.get("hello");

To be clear, “map” is not null, it is an instance of the standard HashMap class from the JDK, the get() method and all the other HashMap methods are the normal ones you have in the JDK, and there has been no bytecode injection. Oh, and the process is not out of memory, hasn’t been out of memory, and the HashMap instance has not been used in more than one thread.

If you cannot figure out the answer, take a peek at issue #159 of the newsletter. One of my colleagues, however, have come up with a deliberately coded “solution” to the problem:

import java.util.HashMap;

public class ShootMyselfInTheFoot {
    private static class Damn {
        // Load
        public int hashCode() {
            return "hello".hashCode();

        // Aim
        public boolean equals(Object obj) {
            obj = obj != null ? null : "";
            return obj.equals(obj);

    public static void main(String[] args) {
        // Fire!
        HashMap map = new HashMap();
        map.put("hello", null);
        map.put(new Damn(), null);

        Object x = map.get("hello");

Left me wondering if might make sense for an advanced obfuscator or copy protection tool inject pieces of such meaningful-looking yet unexpectedly failing code into the application, of course making sure that it never receives control (except if license check has failed a few million CPU cycles before.)

Categories: Java

Tags: ,

The Fastest JVM on Greenland (Perhaps)

The Institute for Arctic Technology at the Technical University of Denmark (DTU) recently worked on a renewable energy project in Greenland. The goal of the project was to determine the impact of combining renewable wind energy with existing diesel generators in small villages. There was just one problem: DTU researchers back in Denmark needed a reliable, affordable way to analyze the data both historically and in real-time. For that solution they turned to Lagoni Engineering Ltd. — and Lagoni turned to Excelsior JET Embedded.

Arctic conditions ruled out upgrading hardware, causing Lagoni to find performance improvements within the existing platform.

“We were looking for a way to reduce the hardware requirements and cost associated with conventional Java, which powers Monatar, our in-house datalogger with a built-in Web server that provides the user interface for the researchers. We found what we needed in Excelsior JET Embedded.”

Thomas Olsen, director of Lagoni Engineering Ltd.

Monatar is a high-performance embedded energy-monitoring device for wind turbine analysis, and it is critical to the DTU researchers’ mission. Excelsior JET Embedded powered — and boosted the performance of — Monatar in the bitter cold of a Greenland winter.

In fact, our product has delivered a 45% improvement on Oracle’s JVM start-up, between 15% and 30% improvement on JVM response, and a full 60% improvement on JVM’s disk footprint size.

Footprint Chart

You can find the remaining charts and further details in the case study.

Categories: Customer Showcase, Excelsior JET, News

Tags: , , , ,

Tools We Use: YourKit Java Profiler

Even though the primary focus of Excelsior has always been on programming languages and their implementation – compilers, managed runtimes (JVM), tooling, etc., our Professional Services Department also offers Java consulting and undertakes long-term application development projects. One such project involved a large distributed system for enterprise email filtering and archiving. The system was implemented in Java and works on top of JBoss, with a large number of automatically scheduled tasks.

At some point the system experienced severe performance deterioration during massive import of email messages. However, our ability to diagnose the problem was substantially undermined by the fact that literally thousands of concurrent threads were running when the problem manifested itself. Isolation of the respective code portions into separate applications was not possible either. A really advanced performance analysis tool was needed.

Read the rest of this entry »

Categories: Tools We Use

Tags: , , ,

Java App As A Single EXE

Despite Sun’s (now Oracle’s) best efforts to push Java to all PCs in the world, people keep coming to our Web site seeking a way to turn a Java app into a single EXE file that would just run on any Windows box without installation.

Problem is, even though Excelsior JET is capable of compiling your Java application classes together with Java SE standard library classes into a single executable, that executable still needs a number of separate files to run: native method libraries, fonts, time zone information, etc.

Those files are needed because Excelsior JET includes the licensed reference implementation of the Java SE standard library, and that’s the way it works. Changing all the places referencing those files and propagating the changes through Java version updates would be prohibitively expensive.

The solution we used to suggest is to export your application as a self-contained directory, which may then be reduced to a single executable using one of the generic application virtualization technologies such as VMware ThinApp.

If you think application virtualization is an overkill for your needs (especially considering the exorbitant costs of the commercial solutions), here is a quick workaround we recently discovered. Using the free 7-Zip archiver, you may turn the self-contained directory produced by JetPackII into an SFX archive that would unpack itself into a temporary directory, launch your application, wait for its termination and clean up after itself.

For those of you who want to try it immediately, here is a link to the Knowledge Base article with step-by-step instructions and tips to avoid the UAC prompts and PCA warnings on Windows 7 and Vista:

HOWTO: Create a single EXE from your Java application

Packaging a Private JRE

You may be wondering now why you would need Excelsior JET when you could place a private copy of the JRE alongside your application jars in the SFX archive. This is a very valid question, but I suggest you keep reading to learn about the benefits of using our product compared to a private JRE.

Disk Footprint

I will be using our pet example – RSSOwl RSS reader – again. RSSOwl is implemented as an Eclipse RCP application and itself takes 17 MB when unzipped. It also needs a Java runtime so as to run on any computer, whether Java-enabled or not. I have four options:

  1. Uncompressed application directory with a private JRE
  2. Same packaged into an SFX archive as described above
  3. Natively compiled application exported as a self-contained directory
  4. Same packaged into an SFX archive

And here is the disk footprint chart:

As you may see, even in the uncompressed natively compiled form the application’s disk footprint is not much worse than compressed jars with a private JRE.

Startup Time Impact (can be positive)

Now there is a concern that the intermediate decompression step may substantially increase the overall startup time of the application. At the same time, reading one compressed file sequentially, especially from a slow-seek device such as an optical disk drive, takes less time than reading multiple files in a scattered order. Also, the decompressed files will remain in the disk cache, so the application will then enjoy a very warm start. So if the processor is fast enough to decompress the archive at the pace matching the transfer rate of the device containing the SFX, the application may actually start faster.

I have conducted some measurements to prove or disprove the above speculations. Specifically, I could think of the following scenarios where packaging your app as a single, install-free EXE is desirable:

– You want to place it on the desktop of a digitally challenged friend or family member with the words “when you need X, fast-click this icon twice”;

– You want to place it in a well-known shared folder on your intranet for your non-IT colleagues to use.

– You want to carry it around on a USB stick so as to be able to run it on any PC.

– You want it to run automatically from a CD/DVD (you’ll see why single EXE is desirable in this case as well)

I have run the tests on my desktop (AMD Phenom 9750 Quad-Core, 4GB RAM, Optiarc DVD±RW AD-5260S, Windows 7 Professional 64-bit), measuring startup time as the time to fully display the main window.

You may notice that the decompression overhead is negligible these days even on a midrange desktop PC. Moreover, the use of compression totally eliminates the huge optical drive seek overhead, making Java a viable option for creating “autorun” apps.

I have put the SFX packages on our Web site so that you could test them on your systems.

Download RSSOwl 2.0.6 packaged as a single EXE:

Of course, the generic application virtualization solutions and Portable application creators are way more versatile than the above trick, but they are also way more complex and priced in accordance with that complexityversatility, as this case study nicely illustrates.

Read on for more test results »

Categories: Excelsior JET, Java

Tags: , , , ,

Native Compiled Intellij IDEA Release Notes

Some time ago, JetBrains introduced a free edition of its brightest Intellij IDEA IDE. Excelsior used this opportunity to native compile and package this edition of IDEA with Excelsior JET and made the compiled version freely available.

We have been working with the native compiled IDEA for a few months and found one major distinction: long lasting GC pauses no longer appear when using the IDE.

Try it yourselves: Intellij IDEA 9.0.310.5.2 Community Edition is available for download at Excelsior JET Application Gallery!

Develop with pleasure!

Note for IDEA plug-in developers.
To compile and run your own plug-ins to IDEA, copy two directories

IDEA Home/lib
IDEA Home/plugins

from the original installation to native compiled one. We did not include these IDEA jars in the native package because they are not needed to run the pre-compiled IDE. However, the original classes are required for plug-in development, which can be enabled by simply copying the above directories.

Categories: Excelsior JET, Java

Tags: ,

Excelsior JET Secures Intellectual Property for the Mobile Sales Force

This case study shows how Avisod LLC uses Excelsior JET to protect their Tomcat Web applications from potential security risks of reverse engineering.

Excelsior JET for Apache Tomcat case study

By: Karl Self, CIO
Avisod LLC

Avisod LLC, a software company that creates a private communications channel for its customers, has a geographically diverse sales force constantly on the move.

In our Quick Serve Restaurant (QSR) vertical, the sales force needed to demonstrate the power of their unique hardware and software solution that included a Java Web application running on Apache Tomcat.

The advancements of decompilers, the increasing reliance on external configuration within Java Web applications, and the increasing cost and complexity of obfuscator software can make for sleepless nights on product teams. Excelsior JET eliminates those concerns through an easy to use interface capable of providing protection for Java Web applications running on Tomcat 5 and above.

Using Excelsior JET 7.2, we were able to secure our Java Web application running on Apache Tomcat 5.5 in less than hour.

Administration Dashboard of Avisod’s L3, an innovative messaging system that delivers targeted text and video messages to individuals on demand.

With JET’s AOT feature, the web container, application code, and JRE were compiled into native binary code. Now our sales force can move freely through airports, train station, hotels, and customer sites knowing Avisod’s intellectual property is safe from potential security risks of traditional decompilers.

Given the alternative’s cost, both in product cost and training, Excelsior JET was an easy choice. Beyond securing Avisod’s intellectual property, Excelsior’s JET 7.2 Enterprise Edition also provides the additional benefits of improved performance and reduced cold startup time. Salesmen typically have only a few minutes of face to face time with potential customers. Every second counts and the Excelsior’s solution helped Avisod’s sales force to make the most of every second.

Excelsior JET provided us with best in class security for our Java Web application giving us more time to focus on our clients and improving our product line.

Categories: Excelsior JET, Java, Tomcat

Tags: , ,

CERT Secure Coding Standard for Java: Theory and Practice

The CERT Secure Coding Standard for Java is a comprehensive set of rules and recommendations for writing secure Java applications. If you care about the security of Java code that you write, make sure to check it out (the C Secure Coding Standard has already made it into a book, and its C++ sibling is in progress, just in case.)

In practice, however, developers that read secure coding guidelines or best practices documents mostly apply the new knowledge to their future work. In the best case, they may have the time to review the code they have written recently. And even then, their now-more-secure code may be just a tiny portion of a large enterprise application combining lots of legacy stuff with code written in other departments, commercial components, etc., running on top of an open-source framework inside a proprietary container.

Even with the help of static code analysis tools, the costs of discovering and eliminating all the security vulnerabilities in such an application may be prohibitive. However, the costs of reducing their exposure may be acceptable. But why is the level of such exposure so high for Java apps in the first place?

For further discussion, continue to my article “Protect Your Java Code – Through Obfuscation And Beyond“.

Excelsior provides practical solutions for the protection of desktop applications based on Eclipse RCP, Tomcat Web applications, and plain Java SE applications.

Categories: Java

Tags: , ,