Jump to content
Excelsior Forums

AlexM

Members
  • Content count

    0
  • Joined

  • Last visited

Everything posted by AlexM

  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
  16. Using JCE with native compiled application

    Hi, You can install "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6" into JRE in the Excelsior JET profile. Instead of copying jar files to <JRE-home>/lib/security copy them to <JET-home>/profile<profile-name>/jre/lib/security where <JET-home> is Excelsior JET installation directory, and <profile-name> - name of the JET profile you use, usually it matches the Java version (for example, 1.6.0_20). You can run JET Setup to check which JET profile is active, if there are multiple profiles. -- Regards, AlexM
  17. Yet another NullPointerException

    Hi Simon, Do you use native libraries in your application? Random NPEs can be caused by subtle bugs in native libraries. Try to stress-test your application to figure out how to reproduce NPE. If the error can be reproduced, then we will be able to debug it and figure out what happens. You can send your sample to Excelsior JET support.
  18. What is the correct location of runtime-provided JARs?

    Excelsior JET supports standard Java SE dynamic class loading. For your case, I see several options: 1) Specify jar files in classpath as usual. If they are present at run time, they will be picked by standard application class loader and classes will be loaded. 2) Use Java extensions mechanism. You can drop your jar files into default extensions dir (<JET_HOME>/profile<Java version>/jre/lib/ext for development system or <APP_ROOT>/rt/lib/ext after deployment). Extensions directory can be overridden with java.ext.dirs system property. Note that you can set paths in system properties relative to application ${Root} in JetPackII. 3) Write your own custom class loader, or use one of the existing, such as java.net.URLClassLoader. Note that all dynamically loaded classes are JIT-compiled, so be sure to check JIT options: selection of fast vs. optimizing JITs, JIT caching etc.
  19. JetPack - Replace only if newer

    Hi, Unfortunately, this feature is not currently supported in JetPackII. If it is critical for your application, you can do the following: 1) prepare a self-contained directory with JetPackII and then deploy it using a third-party installer which supports such kind of file replacement policy; 2) issue a feature request (http://www.excelsior-usa.com/jetfr.php) and wait until it will be implemented; 3) contact us at java@excelsior-usa.com to discuss urgent implementation of this feature on consultancy basis. Regards, --AlexM
  20. F941 Out of Memory Error

    Hi, Unfortunately, it seems that your class cannot be compiled by the current version of Excelsior JET. However, 500k class file is not so large and it should not cause such a problem. Try to extract it from jar file and compile alone (you can set "+gendll -dllname=foo" compiler options if class does not contain main method). Also, if you could send us (java@excelsior-usa.com) the class/jar file which provokes the error, we could inspect it and see if we can do anything to decrease compiler memory consumption in this case. -AlexM
  21. Explicit Mixed Compilation Model

    Hi, You can include missing jar files into classpath after compilation by setting the CLASSPATH environment variable. Note that CLASSPATH environment is used on development systems only and won't work after deployment. So be sure to explicitly set "java.class.path" property in JetPackII when preparing the installation package. Another option is to "fool" the compiler by replacing jar files intended for mixed compilation with empty jars for the duration of compilation. But do not forget to restore the jar files after compilation -AlexM
  22. Runtime error #9(trap) in Jet

    Hi, In fact, trap #9 is an error reported by system exception/signal handler, installed by Excelsior JET runtime. On windows, it stands for EXCEPTION_PRIV_INSTRUCTION - "The thread tried to execute an instruction whose operation is not allowed in the current machine mode." On Linux, it stands for SIGILL signal with ILL_PRVOPC code. Usually it means that instruction pointer points to some invalid instruction (and probably it is out of executable code segment). It could be caused by plenty of reasons. Regards, -AlexM
  23. Runtime error #9(trap) in Jet

    Hi, "Runtime error #9(trap)" is one of internal JET errors which may be caused by plenty of various reasons. The first thing I would suggest is to try the latest Excelsior JET and check if the problem appears on it. You can download evaluation version from http://www.excelsior-usa.com/jetdleval.html. In general, we cannot investigate such issues without debugging the application and reproducing the error. So the fastest way to find out what caused this error is to send us a sample reproducing it, or provide a remote access to the system where the error appears. You can contact us by sending all information to java@excelsior-usa.com. Be sure to include information about version of Excelsior JET, OS version, CPU and RAM capacity. However in most cases the reason of such problems is incorrect native method or JNI misuse. If you are using native libraries (your own or 3rd-party), then it is a good idea to run your application with "-Xcheck:jni" option enabled on Sun JRE: java -Xcheck:jni -cp foo.jar MyMain Regards, -AlexM
  24. Calling DLL created via JET from Java

    Hello, You can reference Java classes compiled into DLL as usual. So in your example you can write something like public class TestDLL { public static void main(String[] args) { MyDLL.getId("XXXX"); } } For several complete examples, take a look at JET/samples/DLL. Also, before trying to build application consisting of multiple parts (DLL/EXE), I would recommend you to read JET User's Guide, chapter "Dynamic Linking", section "Multi-component applications". -AlexM
  25. JET's Bug When use JNI....

    The outbuf has a type "char*" and in the assignment outbuf[i] = 0x00ff0000; //(R=255 G=0 B=0 indicates it's a red image ) the constant is truncated to char type. As (char)0x00ff0000 == 0, your code fills outbuf with zeroes. The correct code should look like int* outbuf = (int*) env->GetIntArrayElements(jbuffer, NULL); for (int i =0 ;i<512*512; i++) // the image buffer is 512 * 512 { outbuf[i] = 0x00ff0000; //(R=255 G=0 B=0 indicates it's a red image ) } Note, that this is a bug in your C code and it does not relate to Excelsior JET in any way. Regards, AlexM
×