Support’s Fairy Tales
Definition (Murphy). A working program is one that has only unobserved bugs.
From time to time, our customers send us defect reports like this
My app works fine under Sun JVM and does not work after compilation with Excelsior JET. Please fix the bug.
Does it mean that the bug lurks in Excelsior JET? The answer is ?maybe?. Of course, there are bugs escaped our QA and any submission of your defect reports is always welcome. However, sometimes, such problems appear because some code was not properly written in the application or in third-party components it uses.
We decided to publish examples of such support cases and hope that it will help you write correct code and reduce the workload on our Support (a bit). 
And so we begin…
Story 1. White List
One day a user submitted the 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 create an EXE using JET 4.8 and got the following Error:
Exception in thread “main”
com.thoughtworks.xstream.converters.reflection.
ObjectAccessException: Invalid final field
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”.
Fortunately, the next version of XStream did not have such a “face control” checking code. We recommended the user to switch to it and the problem has gone.
The only thing that reassured us is that some of other Java SE Licensees were not listed too.
***
Other Support’s Fairy Tales will be published in this blog as well as in Excelsior JET forum. Stay tuned!
