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: , , , , ,

Excelsior JET 11 Beta 2 Adds A Long-Awaited Feature

We have published Excelsior JET 11 beta 2 for all five platforms.

Version 11 Highlights

  • Java SE 8 and JavaFX 8 support
  • 99.9999% of JCK8 tests passed

New in this beta

  • Startup time improvement technologies are now available in the 64‑bit versions as well.
  • Command-line interface to JetPackII. After a long last, you can package your apps without invoking the JetPackII GUI:

    xpack -add-file c:\work\MyApp\native\MyApp.exe /bin ^
          -backend excelsior-installer ^
          -company MyCompany ^
          -product MyProduct ^ 
          -eula c:\work\MyApp\MyApp.license ^
          -target c:\work\MyApp\installer\MyApp-setup.exe

    Version 11 will not support some features of the JetPackII GUI, but we plan to add them all later.

Known Issues

  • Startup Accelerator is missing in the OS X version and will be added at some point after release.
  • JET-8055: On Linux, application may crash if run from a directory with spaces in the pathname and the Startup Accelerator is enabled.
  • JET-8040: Eclipse RCP applications may not work on 64-bit Ubuntu if created with Eclipse 4.3

Download Excelsior JET 11 beta 2 Now

Categories: Excelsior JET, News

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: , , , ,

Comparative Study of Java Startup Time

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

Categories: Excelsior JET, Java

Tags: , ,

|