Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About AlexM

  • Rank
  • Birthday January 1

Profile Information

  • Gender
    Not Telling
  1. Upgrade from 4.5

    Hi, Excelsior JET does not provide facilities for automatic updates. You can use the following approach to update your application: Compile your application with the latest version of Excelsior JET. Package it to a self-contained directory. Create an updating launcher which removes the old files and moves the new files into their place. You can make it as .bat file or write in C. This launcher should wait until its parent executable is terminated. Send the self-contained directory (to a subdirectory of the installation directory) along with updating launcher. Instruct the application to run updating launcher and exit. Regards, -AlexM
  2. ProGuard with Excelsior JET

    Hi, I suggest you to manually remove all *_jetpdb directories and rebuild the application. Also, if you divide your application into several components (DLLs and EXE), then check how classes are divided into components (there should be no duplications). Name obfuscation can be used to reduce size of the application and better hide class/method names. Control flow/data flow obfuscation is not recommended as it may have impact on performance and it is almost useless if application is compiled with Excelsior JET. It depends on the obfuscator. I can confirm that ProGuard is compatible with Excelsior JET. Regards, -AlexM
  3. Hi Blake, Unfortunately, you cannot add extra languages to the installer on your own. Please contact us via java at excelsior-usa.com e-mail if you would like to participate in the localization of installers produced with Excelsior JET. Regards, -AlexM
  4. Memory Leaks in 7.6

    Hi James, In this situation you can set the "jet.gc.stat" and "jet.gc.verbose.out.of.memory" properties and run your application: set JETVMPROP=-Djet.gc.stat -Djet.gc.verbose.out.of.memory App.exe "jet.gc.verbose.out.of.memory" property enables printing of the reason of OutOfMemoryError. "jet.gc.stat" enables gathering of GC statistics. When it is enabled, JET runtime creates "jet.gcstat.log" file in the current directory. Its format is not user-friendly, so it is a good idea to send GC statistics logs to Excelsior Support. So, please collect GC statistics logs from 7.6 and 7.2, and send them to Excelsior Support. Also, include JET project files (.prj and .jpn) you have used to compile the application with JET 7.2 and JET 7.6. Regards, -AlexM
  5. Hi Simon, In the full stack trace mode you have mentioned JET attempts to provide line numbers if possible. In certain cases it may omit them, but you should see something like "Unknown Source" or "foo.class:0". However, note that Excelsior JET takes line numbers from the class files. You can receive such stack traces if class files omit line numbers or they are incorrect. What Java compiler did you use to compile your java sources to class files? Did you enable generation of debugging information when compiling with Java compiler (for example, using javac "-g" switch)? Did you use some tool to post-process class files, such as obfuscator or pack200, before compiling them with Excelsior JET? Regards, --AlexM
  6. JET compiled Application Fails to Run

    Hi, This error message indicates that the class is not verifiable. It violates certain class file constraints which should be checked by JVM. Do you use "-Xverify:none" option when you run your application with Oracle JRE? Regards, -AlexM
  7. Hi, Indeed, Excelsior JET does not support passing of unicode environment to a new process. However, it can be implemented in a hotfix to Excelsior JET 7.6. Please contact our Support department via java at excelsior-usa.com e-mail. Include details about your Excelsior JET version and edition. -AlexM
  8. Hi, First of all, please use JetPackII tool (included in JET) in order to package and deploy your application to the target system. For more information, see JET User's Guide, chapter "Deployment automation" Secondly, please make sure that LD_LIBRARY_PATH is set for JET runtime. If JET runtime is installed to a directory ${JETRT}, then LD_LIBRARY_PATH should contain ${JETRT}/jre/lib/i386:${JETRT}/jre/lib/i386/jetvm On the development system ${JETRT} stands for <JET installation directory>/profile<Java version>. On the target system it depends on the application installation path and JetPackII settings ("rt" subdirectory of application directory by default). Setting of LD_LIBRARY_PATH is usually performed when JET-compiled executable is launched, but in your case (Invocation DLL) it should be set manually. Note that LD_LIBRARY_PATH should not point to any other JDK/JREs including Oracle JRE. Usually, when compiling C code, JDK is used just to specify directories with jni.h/jni_md.h include files. These include files specify JNI interface which is the same for different JDK micro-versions (and even for different JVMs). So, in such case, the difference in the micro-version of installed JDKs doesn't matter. Regards, -AlexM
  9. Spring support?

    It seems that Spring (or JAXB?) generates classes with illegal names. The class name no.bbc.basis.server.ws.BagFlightInfo$JaxbAccessorM_getBagBins_setBagBins_[Ljava_lang_Short; is not legal according to Java Virtual Machine specification (it contains forbidden characters '[' and ';'). Oracle JRE sometimes omit this class format check. However, you can force Oracle JRE to make all checks. Please run your application on Oracle JRE with the following additional JVM argument: -Xverify:all Please let us know if it fails with the similar exception. If it is the case, as a workaround you can disable verification checks in JIT compiler of Excelsior JET by defining the following system property: jet.jit.compiler.options=+noverify Regards, -AlexM
  10. Spring support?

    Hi Mike, It seems that you are trying to use Java 7 class files. Note that JET does not support Java 7 yet. For more verbose diagnostic, please add the property jet.jit.loud on the page "Start" (type it into the "Java System Properties" text area on the bottom right of the page), and perform a test run again. Please post here the extra output describing error. Regards, -AlexM
  11. Memory-addressing constraints

    Correct. Address space for 32-bit applications is limited to 4 Gb. In practice, 32-bit Java applications can use up to 1.2-3.5 Gb of memory for Java heap depending on OS and system configuration. 64-bit version of Excelsior JET is not available yet, but it is actively developed right now. It will allow Java heaps > 4Gb.
  12. SSL's

    Hi, Please clarify, which Excelsior product do you use? If you compile your application with Excelsior JET, then, please, contact support by filling this form.
  13. Incremental compilation ...

    In fact rationale is simple: our development resources are limited, but there are a lot of features and improvements which can be made. And it is not easy to implement fully-functional smart recompilation in presence of global optimizations. For example, consider the following case: changes in a class can influence to code generation of another completely unrelated class, as type hierarchy changes and the results of global analysis become invalid. In the older versions of Excelsior JET there was a smart recompilation mode, but it was a source of subtle bugs. And since then compiler and its optimizer evolved a lot, so supporting this mode would require much more efforts. So we have decided to remove this mode for now. In future, we may change our mind and implement smart recompilation as we understand concerns of our customers about compilation time. But for now our main goal is to make a 64-bit version of Excelsior JET. Best Regards, -AlexM
  14. Problem with C# example

    Hi Ash, Thank you for the suggestion. I have corrected build.bat and included this information into readme.txt of this sample (in the future versions of Excelsior JET). Best regards, --AlexM
  15. Problem with C# example

    Hi Ash, It seems that you are trying to run this sample on x64 system. By default, C# compiler targets "anycpu" platform, which turns into x64 on 64-bit system and x86 on 32-bit system. But DLLs generated in the sample (both C DLL and Java DLL) are 32-bit. 32-bit DLLs cannot be used in x64 process. To solve this problem, force C# compiler to target x86 platform. Edit build.bat and change the line csc Test.cs to csc /platform:x86 Test.cs Then rebuild a sample. Best regards --AlexM