According to the Support Policy statement, Excelsior JET 6.0 has reached Product End Of Life status. We encourage customers of this version to migrate to more recent versions to receive the support services under valid Support Contracts.
If you need help in migrating to a newer version of Excelsior JET,
do not hesitate to contact us.
Dead locks in “oversynchronized” code and data races provoked by “undersynchronized” code are serious issues in parallel programming. Typically, they appear as volatile, hardly reproducible bugs in multi-threaded applications, and often remain undiscovered during QA. After shipping software products, such issues bite the end users and significantly increase the maintenance cost.
The main reason of such “volatility” is that non-deterministic thread scheduling may produce billions of program execution states and only a few of them are erroneous. As a result, it is tough to meet the conditions necessary to stably reproduce the bugs with stress tests.
As known from practice, altering the picture of thread scheduling, for example by improving code performance, may help reveal such latent issues. In the case of Java, it may be done by running the application not only on the standard JRE, but also on other JVMs which may provide higher execution speed.
Charles O’Dale from Senomix Software Inc. kindly agreed to write down such case occurred when testing a client-server application featuring heavy multi-threading. Senomix is a long-term Excelsior’s customer using Excelsior JET, a Java SE 6 JVM with AOT compiler. Native pre-compilation of Java code often provides better performance as compared to traditional JIT-based JVMs, especially on application startup. Here goes the Senomix’ story.
By Charles O’Dale
Senomix Software Inc.
May 2010
As part of the development process of Senomix Time Tracking, our networked software, a number of automated tests have been created to stress-test the system and ensure any one-in-a-million threading race conditions will be caught before release. In a typical test, test client applications are left to ‘attack’ our application’s server over the course of a few hours and simulate the amount of traffic the system could expect to see over a few centuries of real-time use. If the server continues to operate through that stress test without any difficulties, we can then conclude it will be able to smoothly run through any peak-period traffic an office will experience. The server program is then packaged up as an Excelsior JET executable and tested again before being distributed to our customers for installation.
Our problem occurred when performing this final set of tests for the latest version of our system with the executable compiled under Excelsior JET. Although the Java .jar version of our server program was able to handle any amount of network traffic our tests could throw at it when run against Sun’s JRE, the JET-compiled executable would freeze within a few minutes, with the application halting at a seemingly random location in the code on every interruption.
Under normal circumstances we would conclude that a new race condition had been discovered and go about correcting it. However, every test run against the pure Java version of our server would perform flawlessly when operated on Sun’s JRE — only tests run against the JET-compiled executable resulted in failure. After implementing every check we could think of to prevent deadlock in the executable program’s threads, we concluded there must be a problem with JET and set about informing Excelsior of the issue.
Our test environment made duplicating this problem a straight-forward process, and the test applications and troublesome Java server jar were sent along by e-mail to Excelsior for review. Excelsior’s support team were then able to use their test environment to duplicate the problem we were seeing in the executable and set about identifying the underlying cause.
It turned out the problem was in our own code after all! A newly created thread involved in communication had its run method mistakenly set to be synchronized, with that declaration causing a deadlock in the faster code generated by the JET compiler.
After correcting that mistaken declaration of:
public synchronized void run()to be:
public void run()The JET-compiled executable ran flawlessly, with the program demonstrating the same reliability as our standard Java jar file.
If our system’s server application only ever operated as a standard Java jar, it’s unlikely we would ever encounter a problem with this code (as the conditions required to bring about the deadlock would truly be a one-in-a-billion event). However, the improved efficiency of the Excelsior JET
executable increased thread speed just enough to bring this problem to light.
If another office experienced a similar condition, with a Java program operating fine but failing once compiled into an JET executable, we would recommend they find a way to duplicate the problem with a similar reproducible test. If internal examination of that problem code could not identify the source of the difficulty, forwarding that test to Excelsior’s support team for their review may provide helpful insights similar to those which Excelsior delivered to us.
Excelsior JET JVM: product info
A Tale of Four JVMs and One App Server: yet another article on revealing latent bugs by testing with different JVMs
We have donated free Excelsior JET licenses to the SimuLab project, aimed at creating an open source flight simulator. They were apparently impressed by the performance of the native build:
- CPU peaks (highest cycle consumption): JRE 62%, JET 53%
- Memory: JRE 227MB, JET 133MB (highlighting mine – DL)
- Startup: not measured but JET outperformed the JRE BY FAR as expected.
If you are passionate about flight simulators and Java, check out SimuLab and consider contributing some of your spare time or money (does anyone in today’s world still have any of these?)
If you are already working on an interesting non-commercial Java app and feel that the use of Excelsior JET might benefit its end users, feel free to apply for a free license.
Tags: free, memory, performance
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.
Click the Excelsior JET button in the Eclipse toolbar.
The export wizard window will appear.
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.
Click Finish. The exporting process will start.
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.
You may find detailed instructions and Update Site URL to install this plug-in into your Eclipse IDE on this page.
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
Excelsior JET 7.0 Maintenance Pack 2 fixes a few customer issues and enables the use of the all-new Eclipse IDE plugin for RCP developers.
Despite Excelsior JET is a compliant Java SE VM, our engineering team used to receive complaints like:
My app works fine under Sun JVM and does not work after compilation with Excelsior JET. Please fix the bug.
For the truth to be told, some (popular) Java components are written so as to work only with certain Java implementations. I believe it’s a bad practice that will strike back, sooner or later. Here goes an example.
Back in 2007, a user submitted the following bug report:
I have written a program which just uses XStream (xstream-1.1.3.jar) to create the XML tag for a final class variable in my program. I am able to execute directly using the JVM on my system.
Then I tried to compile to native EXE with Excelsior JET 4.8 and got the following Error:
Exception in thread “main”
com.thoughtworks.xstream.converters.reflection.ObjectAccessException: Invalid final field xmltest.Main.theValue
We inspected the code in the XStream library that provoked throwing the exception and, to our big surprise, found the following:
private boolean canUseSun14ReflectionProvider() {
return (isSun() || isApple() || isHPUX() || isIBM() || isBlackdown()) && is14() && loadClass("sun.misc.Unsafe") != null;
}
Well, it proved that we are not on the “white list”! By the way, the Java SE implementation by SAP was also affected by this issue. I must say that since the time we revealed the problem, we repeatedly bumped into it in different Java applications.
One drop of poison infects the whole tun of wine.
Got tired of receiving the complaints, we finally made a trick. The checks if the VM is “trustworthy” are implemented as follows:
private static boolean isSun() {
return System.getProperty("java.vm.vendor").indexOf("Sun") != -1;
}
We changed the value of java.vm.vendor from "Excelsior LLC" to "Sun Java Licensee - Excelsior LLC". Everything went well and we had a rest… for some time.
Guess what will happen when the value of java.vm.vendor in the HotSpot VM turns to "Oracle Corporation".
Recently we have started receiving complaints from Excelsior JET evaluation users about virus detection in certain binaries included with Excelsior JET. Specifically, the file
JET-Home\bin\xinst_lzma.exe
triggers anti-virus systems by Avira and Kaspersky Lab.
A quick check with building the file from source code has shown that it’s false positive virus detection. We have contacted the vendors of the anti-virus systems and got the results confirmed with promises to fix false detection in future versions of their products.
Here go the confirmations.
Issue in Avira’s on-line tracker
E-mail from Kaspersky Lab:
False positive virus detection [KLAN-65739172]
Hello,
Sorry, it was a false detection. It will be fixed in the next update.
Thank you for your help.——————————————-
Best wishes, Pavel Firsov.
Virus analyst , Kaspersky Lab.
_____________________________
Ph.: +7(095)797-8700
Fax.: +7 (495) 948-43-31
newvirus@kaspersky.com
http://www.kaspersky.com http://www.viruslist.com
See also the article Occasional false positives in Kaspersky Lab’s products
Excelsior ran a booth at EclipseCon 2010 in Santa Clara, CA where we presented our solution for securing Eclipse RCP. The Exhibit Area located in the Hyatt mezzanine was a crossroad of the conference: attendees went to and from session rooms running through the area.
The conference was very interesting and covered lots of topics on the Eclipse technology and ecosystem. As a result, it was a little bit challenging to capture people’s attention and start conversation because they all were engaged in the conference activity. Nevertheless, we coped with that.
Things made easy Tuesday evening that was party time in the Exhibit Area. People had more time to chat with sponsors and see what they are doing.
We met and talked to many colleagues and potential customers, not only at our booth but also at the conference sessions and receptions that held each evening. At the parties, the EclipseCon organizers generously distributed free beer coupons, I confirm.
See the conference photos.
We do not do trade shows often. In fact, we did it only once, and that was JavaOne 2004. This year we have decided to try a more targeted approach, and will be showcasing our Eclipse RCP application security solution at EclipseCon, March 22-25, 2010 in Santa Clara, CA.
Also on display will be an illustration of interoperability of Excelsior JET with conventional Java tools, using the Java GUI testing tool QF-Test from QFS as an example.
Come talk to us and see the natively compiled Eclipse IDE automatically tested at Booth #13!
We have run a customer satisfaction survey recently and one of the repeating complaints was about the lagged releases of add-ons for new Java versions. We have listened, so here goes the Java SE 6 Update 18 Support Add-on For Excelsior JET 7.0, accompanied by Maintenance Pack 1.
Java SE 6 Update 18 was the last release from Sun and is the first that officially supports Windows 7. It fixes in particiular the JFileChooser missing icons issue. So if you are writing Swing apps for Windows 7 users, update your Excelsior JET 7.0 now!
