New Case Study: MSSQLTracker (Tomcat Web App)

MSSQLTracker is a free (as in beer) solution that makes the life of Microsoft SQL Server administrators easier. Implemented as a Java Web application supposed to run on Apache Tomcat, it would have been an easy target for malicious users tampering with the code of server management tools. After a careful study, Ben Dawson, the author of MSSQLTracker, chose Excelsior JET to protect his intellectual property and his users’ data.

Read the full case study, then learn how Excelsior JET can help you protect your Java Web applications.

Categories: Customer Showcase, Excelsior JET

Tags: , , ,

Excelsior JET 7.0 Ships

As promised, Excelsior JET 7.0 enables you to protect your Java Web applications running on Apache Tomcat by compiling them together with the Tomcat server itself into an optimized native executable.

Multi-app executables enable you to compile several applications into one executable, thus maximizing code and data sharing at run time. Another benefit is the ability to specify JVM options and Java system properties on the command-line in the conventional manner:


MyApp -Xmx512m -Dmonitor.port=7000 com.XYZ.server.Main
MyApp -Dport=7000 com.XYZ.monitor.Main

On Windows, the same binary may now be run as a conventional executable and installed as a service.

Speaking about Windows and sevens, Excelsior JET 7.0 has passed the Java SE 6 compatibility testsuite (JCK) on Windows 7 and is supported on that platform.

An important usability enhancement, performance and stability improvements, and reduced memory usage are also waiting for you to enjoy them!

Full list of new features and improvements in Excelsior JET 7.0

Download Excelsior JET 7.0 Evaluation Package

Categories: Excelsior JET, News, Product Updates, Tomcat

Tags: , ,

Hiding Apache Tomcat Configuration Files

Several beta testers looking to protect their Tomcat Web applications with Excelsior JET 7.0 have told us they also do not want their customers and prospects inspect or modify their Apache Tomcat configuration files. The just released beta 3 adds the capability to hide the Tomcat conf/ directory and its contents. The respective checkbox is located in the Misc pane on page Target of the JET Control Panel.

Another new feature is Tomcat customization. Now you may extend the boot classpath, change the main class and the Windows service main class, and specify additional VM options for the Tomcat server. Look for the Customize Tomcat button on the Start page.

Those who played with the previous two betas must have already guessed that the JET Control Panel now supports Tomcat projects. Packaging is still command-line only.

Finally, beta 3 supports more recent Java versions: Java SE 6.0 Update 16 (1.6.0_16) and J2SE 5.0 Update 21 (1.5.0_21).

Download Excelsior JET 7.0 beta 3 for Windows
Download Excelsior JET 7.0 beta 3 for Linux

Categories: Excelsior JET

Tags:

Excelsior JET 7.0 Beta Announcement In `tomcat-users’

Yesterday I announced the Excelsior JET 7.0 public beta program in the `tomcat-users’ mailing list at apache.org. The announcement has sparked a small discussion, but the follow-up would be a bit too long for email to my taste, so I am responding here and will then send a link to this post to the mailing list.

I will start with the concern that is easier to address. Leon Rosenberg wrote:

Wouldn’t that make the application slower? I assume this compiled code can’t be uncompiled and optimized by the hotspot, so it is not for performance.

Excelsior JET is an optimizing compiler originally developed as a tool for accelerating Java applications. True, Sun HotSpot Server 6 is very good, and so is Oracle JRockit, but there is no silver bullet – we have happy customers reporting substantial speedup of their apps as a result of AOT compilation, and we have prospects canceling evaluation because of the slowdown. I can point you to some third-party benchmarks, but your mileage will vary, one way or another.

Leon went on to write:

As for preventing decompilation, how many people/companies are actually delivering a war which they need to protect from decompiling? How many people would install such a product, one they can’t configure anymore, one that is even infectable by viruses?

We fully realize that Excelsior JET is unlikely replace the conventional JRE in the majority of Tomcat installations (unless Oracle starts charging for the JRE. 🙂 ) So the question is if there are any Web application authors who might need our solution? We are sure there are some, and here is why:

  • We already have a few paying customers (technically it has been possible to compile Tomcat for years, but the process was difficult and error prone, plus the current version imposes some restrictions on your Web apps if you need protection, yet that does not stop people who really want it)
  • Customers and prospects keep asking if they could use our tool to protect their Web applications
  • “Tomcat” is the #5 search query of all times on our Web site, trailing only “SWT”, “Eclipse”, “DLL”, and “Swing”.

As you may see, our decision to add this feature is 100% customer-driven!

I have also spoken to the author of a popular Tomcat book, and he sees deployment as a big issue. Not deployment of web applications onto a Tomcat instance, but rather deployment of the entire solution, that is, Java Runtime plus Tomcat plus one or more Web applications. Ah, and don’t forget the database engine!

Imagine you are in sales engineering and a prospective customer wants to test drive your app just to get a feeling of its capabilities and such. If you could give them a single installer that would install and run on any manager’s PC with little to no configuration, and at the same time would be much more difficult to tamper with, would not you call this a competitive advantage?

The inability to configure Tomcat after native compilation is a misconception. If you download and install one of the sample packages, you would notice that the wars and jars are gone, but the Tomcat directory structure is retained and you still have the startup scripts and XML descriptors at your disposal. (Some people asked for an option to hide these as well, though.)

Moreover, Excelsior JET Runtime includes a JIT compiler, otherwise it would not have been certified Java Compatible and our company would not appear in the list of Java Licensees. So you may drop a WAR into webapps/ and it will work as usual. (Of course, out JIT is much less sophisticated than HotSpot, so that particular app would start slower and its response time would be worse than if you AOT-compiled it.)

As for viruses, last lime I checked java.exe was not immune to them either. 😉

Ramzi Khlil wrote:

I think it’s not a good idea especially when application are subject to modification frequetly or if we plan to deploy a new application on the server. Tomcat has a very interesting feature which allows user to load application on fly without closing the server. But If I compile tomcat and webapps into single package, I will lost this feature.

I see that’s a very limited functionnality.

Again, there are use cases where you want to prevent (unauthorized) modification of your application. As Serge Fonville noted in his follow-up, there are ISVs whose shrink-wrapped products are essentially Web applications. Sure, those use cases may constitute a minority, but what we hear from our customers and prospects makes us believe it is not such a limited functionality.

Finally, I cannot resist quoting the André Warnier’s follow-up almost entirely:

…I have a number of corporate customers who have sub-contracted their
IT infrastructure to an external service company. In my experience these external people then, usually, tend to adopt the “umbrella” attitude, whereby they want every other external software supplier to supply their software in a manner that will cause themselves the least work and the least trouble. In other words, their ideal is that the software be delivered in the form of a single executable, pre-parameterised so that they don’t even have to choose options in an installer, and that they would not bear any responsibility if anything should not work as expected.

They are certainly not interested in even having to think about tricky customising options.

I am not saying that these are my preferred kind of customers. (I prefer smart ones, up to a point).

But this is a “use case” for the proposed package, it seems to me.

Categories: Excelsior JET, Java

Tags: , ,

|