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.