Protect Java Web Applications

Excelsior JET is a certified Java SE 8 JVM with an Ahead-Of-Time compiler and installation toolkit.

In particular, you can use it to compile Apache Tomcat together with your Web applications into a native code executable and distribute it without the original class/WAR files or dependency on the JDK.

Compilation to native code protects your intellectual property and substantially improves the security of your Web applications. It makes IP theft, code tampering, and discovery of security vulnerabilities involve an expensive reverse engineering effort, whereas practically anyone can download and run a free Java decompiler.

It takes just a few mouse clicks to compile your Tomcat Web app to a native binary.

Watch the demo or Download Your Evaluation Copy

Tomcat Version Support Alert

The current version of Excelsior JET supports Apache Tomcat versions 5.0 through 8.0. You can leave your email address below to receive a notification when we add support for Tomcat 8.5 and the upcoming Tomcat 9 release.

When you add support for the latest versions of Apache Tomcat,
drop me a line at .

Privacy Notice: This is a double opt-in mailing list managed by Campaign Monitor. We won't share your email address with anyone else. We shall only post to this list once or twice (depending on the Tomcat 9 availability date) and remove it afterwards.

Experts Say


“If you do not want others reading, modifying, and recompiling your web application's source code, Excelsior JET is the best tool to use.”

Jason Brittain
Co-Author of Tomcat: The Definitive Guide
read full quote


Most Java developers know that Java class files are easily decompiled back into Java source code again. What's more, there are now several software tools that can decompile class files into source code that you can easily modify and recompile. The code for compiled servlet class files, JSPs, and any other included proprietary libraries are also as readable as open source software, once they are decompiled. But, when compiled into native code, none of these class decompilation tools work, and the Java program still runs the same. If you do not want others reading, modifying, and recompiling your web application's source code, Excelsior JET is the best tool to use.

book cover

I tried JET 7 with Tomcat 6 and some of my own large and complex web applications, and it worked flawlessly! I was able to natively compile my Tomcat and my webapps into native code that installed and ran just fine. I was pleasantly surprised at how easy it was to compile it all on the first try. Not only did my web applications run flawlessly, they did seem a bit faster than when I run them with the Hotspot JVM. From my tests, JET works great.

“Having tried the three options (hosting, obfuscating and [Excelsior] JET), I am to say I find the latter to be the most powerful tool in my toolbox as of now.”

Nicolas Fränkel,
Author of Learning Vaadin 7, in his blog post on safely giving away web app demos

Customers Say

"We have been able to successfully protect our intellectual property in our enterprise application iExperiment in a public Amazon Machine Image, allowing groups interested in valuating iExperiment to quickly get up and running with it on Amazon Web Service."

Marc Whitlow
President & CEO
Colabrativ, Inc.
read the case study

"Using Excelsior JET to compile Tomcat with our web application into native code, means our Java classes cannot be tampered with, thereby safeguarding our intellectual property."

Ben Dawson
read the case study

News and announcements

Web application protection is now enabled in Excelsior JET Embedded as well

Sample applications

These Web applications are compiled to native code using Excelsior JET:

"Clean" Tomcat 7.0.16
(with standard samples)
Windows (25MB)
Linux (25MB)
Pebble 2.6.2 on Tomcat 7
(blogging tool)
Windows (23MB)
Linux (23MB)


How does it work?

Simply put, Excelsior JET knows how the Tomcat classloaders work. That knowledge enables ahead-of-time compilation of the deployed Web applications and the Tomcat server itself.

Previously, in the general case Web applications could be only handled via the JIT compiler that comes with the JET Runtime, just like it is done by the standard JRE. Unfortunately, that approach did not provide any security as the application classes had to be distributed in the original bytecode form.

What are the known limitations?

As of version 15.3, Excelsior JET imposes some limitations on your Web applications functionality:

  1. All Web applications must be deployed into a subdirectory of Tomcat-Dir. It may be webapps/ or another directory.
  2. Web applications are compiled together with Tomcat into one executable, so hot re-deployment of a running pre-compiled application is not possible. You would need to stop Tomcat, replace the executable, and start it again.
What are the supported platforms?

Windows on x86 (IA-32), x64 (AMD64/Intel 64) or compatible hardware; OS X on x64, and Linux on x86, x64 and ARMv7. For more details, refer to the System Requirements page.

What are the supported Java (micro)versions?

Excelsior JET 15.3 supports Java SE 8 Update 181 (1.8.0_181) out-of-the-box. Support for later versions of Java is provided via maintenance updates.

If your application only runs on Java SE 7, you may downgrade to Excelsior JET 10.5, which was the last one to support that version of Java.

What are the supported versions of Apache Tomcat?

Excelsior JET 15.3 supports Apache Tomcat 5.0.x, 5.5.x, 6.0.x, 7.0.x, and 8.0.x. Version 8.5 is not supported yet.

Do the compiled Tomcat and Web apps start and work faster?

Possibly yes, though we have not focused on performance yet.

Can I compile only certain Web applications to native code and leave the rest intact?

Yes, it is possible. For details, please refer to the User's Guide, Chapter "Tomcat Web applications", section "Compilation", "Step 3: Settings for Web applications".

Can I deploy additional applications on the AOT-compiled Tomcat?

Yes, you can do that using the standard Tomcat deployment procedure. Web applications deployed this way will be handled by the JIT compiler that comes with the JET Runtime.

How does the solution compare to Java obfuscators?

In general, Java obfuscation has quite a few weak points as compared to AOT compilation of Java classes to native code. Specifically for Web applications, the most crucial one is that you may not use name obfuscation because Web containers heavily rely on Java Reflection.


Your feedback and suggestions are very welcome! Please email us at