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 »
Tags: Java, performance, tool, webapps
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:
- Uncompressed application directory with a private JRE
- Same packaged into an SFX archive as described above
- Natively compiled application exported as a self-contained directory
- 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 »
Tags: deployment, exe, footprint, Java, startup time
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.
Tags: Java, performance
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.
Tags: Java, protection, webapps
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.
Tags: Java, protection, secure
The recently issued Excelsior JET 7.2 was, in essence, a maintenance release, because the Excelsior Java team is now mostly focused on the development of the 64-bit version of Excelsior JET. Nevertheless we have managed to include one major feature in this release – Startup Accelerator.
Combined with Startup Optimizer available in previous versions of Excelsior JET, it delivers a noticeable improvement in Java applications startup time. We have prepared a short comparative study backing this statement:
Java vs Native vs Optimized Java
The following startup time comparison includes different RSS feed readers: two native Windows applications (FeedDemon and FeedReader) and one implemented in Java (RSSOwl). The latter was run on the standard JRE 1.6.0_20 and then compiled with Excelsior JET 7.2 Professional Edition/profile 1.6.0_20.
These applications were run on a mid-range laptop (dual-core ULV Intel Celeron SU2300, 2GB RAM), and their warm and cold startup times measured as the time to fully display the main window.
As you can see, the RSSOwl application optimized with Excelsior JET starts:
- 2x to 3x faster than on the JRE
- about as fast as the similar native applications
References
Java Startup Time solution page: optimization guidelines, FAQ
Excelsior JET: product info
Tags: Java, performance, startup time
Nicolas Fränkel in his blog recommends using Excelsior JET to protect your demo Web applications.
Tags: Java, protect, protection, webapps
Excelsior JET Eclipse plug-in for RCP developers enables you to export your Eclipse RCP application in native code form and deploy it in the wild without the easy-to-hack jar files.
Just compare the structure of exported RCP applications to see the difference:

With the Eclipse plug-in for Excelsior JET , the exporting of RCP applications to native code can be done in three simple steps.
STEP 1: Invoke the Export wizard
Click the Excelsior JET button in the Eclipse toolbar.
The export wizard window will appear.
STEP 2: Select destination
You may export your RCP application into a directory as if you were using
the standard Eclipse Product export wizard, or wrap the application
into Excelsior Installer to enhance the end-user experience.

Specify the desired Product Configuration file and enter the path to the destination directory or to the installer executable you wish to create.
STEP 3: Export!
Click Finish. The exporting process will start.

Upon successful completion, a dialog will appear, displaying
the location of the exported application.
From this dialog, you may also get instructions for the headless build of your RCP application with Excelsior JET and test drive the application installer, if you opted for its creation on STEP 2.
Note: Eclipse RCP applications exported with Excelsior JET no longer need
the JRE to run.
Plug-in installation
You may find detailed instructions and Update Site URL to install this plug-in into your Eclipse IDE on this page.
Resources
Whitepaper: Two Ways of Securing Eclipse RCP Applications (obfuscation vs. native pre-compilation.)
Case studies: RCP developers share their experience with Excelsior JET.
Video tutorial: standalone tools providing the advanced features of Excelsior JET, such as startup time optimization, Java Runtime Slim-Down, installer branding, and others.
Excelsior JET for Eclipse RCP page: product information, sample applications, etc.
Tags: deployment, eclipse, Java, plugin, protection, rcp
Our CTO Vitaly Mikheev has posted to Javalobby a new article covering Sun’s Java Kernel and Project Jigsaw and our Java Runtime Slim-Down:
Future in the Past: a Lightweight Java SE Runtime
If you read it, please make sure to vote! Comments are most welcome too.
Tags: Java
Excelsior JET is a compliant Java SE JVM (yes, it has passed the awesome huge JCK testsuite).
Today news: Excelsior JET 6.5 supports the core of Eclipse Runtime (Equinox OSGi) at the JVM level. Specifically, wiring OSGi bundles, consistency checking before execution and lazy activation of OSGi bundles are supported.
What are the benefits of deploying applications with the JVM that serves as an OSGi container?
As Excelsior JET supports ahead-of-time compilation, the developers of commercial Eclipse RCP and Equinox applications benefit from the ultimate code obfuscation and protection of sensitive data: the applications can be compiled down to native code executables and distributed without the original jar files. Java decompilers are left at bay.
Moreover, merging Java and Equinox Runtimes results in the most secure environment for running Eclipse RCP applications. The environment blocks tampering with OSGi bundles and injecting unauthorized code via Java classloading hooks by protecting the Eclipse Runtime itself.
Finally, the consistency of Eclipse RCP applications can be checked statically to prevent run-time errors.
Flash demo, customers’ success stories, sample RCP applications compiled to native code (including the Eclipse IDE) and fully functional trial downloads are available here.
Official press-release
Excelsior JET home page
P.S. This new version of Excelsior JET is mostly focused on Eclipse RCP. However, the implemented Java Runtime technology can be used in other areas where OSGi shines, e.g. for Spring DM. We would greatly appreciate your feedback on this topic.
Tags: eclipse, Java, osgi, rcp