Jump to content
Excelsior Forums

zztop

Excelsior Staff
  • Content count

    0
  • Joined

  • Last visited

Everything posted by zztop

  1. It might be a JNI misuse in the library. Please send an example to reproduce the problem to Support Dept. (java at excelsior-usa.com). We will check it on our end and post a follow-up with the results in this topic.
  2. This topic has been moved to Excelsior Installer / Excelsior Delivery. [iurl]http://www.excelsior-usa.com/forum/index.php?topic=1809.0[/iurl]
  3. zztop

    MOVED: iPhone support

    This topic has been moved to General Discussion. [iurl]http://www.excelsior-usa.com/forum/index.php?topic=1811.0[/iurl]
  4. According to the Sun Microsystems? Java Technology Support and EOL Policy, J2SE 5.0 will have reached its End of Service Life (EOSL) October 8th, 2009: http://java.sun.com/j2se/1.5/ Excelsior JET 7.0, scheduled for release in 4Q 2009, will therefore be the last version with support for J2SE 5.0. Of course, we will continue support Java SE 6 and include the anticipated Java SE 7 in future versions. If you are still using J2SE 5.0, we encourage you to migrate to the new version of Excelsior JET to use the latest J2SE 5.0 microversions, supported in Excelsior JET 7.0. If you need help in migrating to the newer version of Excelsior JET and/or the newer version of the Java technology, or have any questions in connection with the above, please, contact us.
  5. zztop

    64-bit Support

    I'm sorry that we were not able to deliver 64-bit version as initially planned. There were objective reasons for that. I believe you are aware of that the Excelsior JET License Agreement and Excelsior JET Support Contract do not include any obligations w.r.t. features/capabilities to appear in future releases of the product.
  6. I must say that JAVA_TOOL_OPTIONS is quite an unusual way to support locales in Java applications.
  7. You may use the JETVMPROP env. variable (see the JET User's Guide, chapter "Application considerations", section "Java system properties") That's not enforced by the Java standard. Even Sun JRE does not support this variable on some platforms. -------- The next version of Excelsior JET will enable you to specify the VM options directly on the application command line (see What's new in Beta 1 / "Mullti-app executables" at the beta download page)
  8. zztop

    mozSwing doens't work in Vista x64

    Excelsior JET 6.5
  9. zztop

    mozSwing doens't work in Vista x64

    Now it's a detailed report, thank you. We will check it on our end and let you know the results. Note however that the problem may be in JavaXPCOM itself (see this story for example). ----- BTW, does the problem appear if you use the latest version of Excelsior JET?
  10. zztop

    mozSwing doens't work in Vista x64

    Ok. Now could you describe the issue in more details?
  11. zztop

    mozSwing doens't work in Vista x64

    Make sure that you use a Java 6-based profile of Excelsior JET (launch JetSetup and check the active profile). Please be more specific about the probelm
  12. zztop

    SuspendThread failed with error 5

    What's the OS on which the problem appears? Do you use a real box or virtual PC when experiencing the problem?
  13. zztop

    Excelsior JET + JNA to get a transparent window

    Thanks for posting this hint.
  14. zztop

    64 bit JET

    I mean that 1. We did not test applications compiled with outdated versions of Excelsior JET on 64-bit systems. As a result, executables produced by Excelsior JET prior to version 6.0 did not work on 64-bit Windows and Linux at all With the current Excelsior JET 6.5, everything works flawlessly 2. By default, the practically allowed heap size on 32-bit Windows and Linux is less than 2GB. If you run the same binary compiled with Excelsior JET on a 64-bit system, the heap size may be close to 4GB 3. We understand the importance of 64-bit version of Excelsior JET for our customers whose applications may require larger heaps. That's why we are constantly investing our engineering resources in design and development of the port. Please find my answer in this (duplicate) topic
  15. zztop

    Future 64-Bit Support?

    You may address upto 4GB of RAM, if your 32-bit application (compiled with the current version of Excelsior JET) is run under a 64-bit operating system. We have checked that and it works. If you need >4GB, it will be possible only after we release 64-bit version of Excelsior JET. The current status is given in this post.
  16. zztop

    64-bit Support

    Let me make things clear. 1. In all posts concerning the 64-bit port we made the reservation that particular dates are not yet defined. We never undertook any obligations to deliver the 64-bit version according to some schedule. 2. 64-bit port is a mammoth (and therefore expensive) task so before making it the key feature of the next release we must invest enough into preparing the port 3. We do want to release 64-bit version of Excelsior JET The current status is as follows. We continue working on 64-bit port but the amount of resources we are currently spending for it, is not enough to make it the key new feature of the forthcoming release of Excelsior JET. The next checkpoint to make the decision is 4Q 2009 after we will issue Excelsior JET 7.0
  17. zztop

    MOVED: 64 bit JET

    This topic has been moved to General Discussion. [iurl]http://www.excelsior-usa.com/forum/index.php?topic=1744.0[/iurl]
  18. zztop

    64 bit JET

    Probably, you use an outdated version of Excelsior JET. Java applications compiled with the latest Excelsior JET 6.5 work without problems on 64-bit Windows systems (we use them in testing on regular basis)
  19. zztop

    Too big native SWT RCP file

    Note also that 12-15MB is the size of a complete installer that does not have deployment dependencies (JRE installation is not required on target machines).
  20. It would be nice if Excelsior JET would allow compiling more than one application into a single executable with selecting a particular application at launch time via command line arguments. This would enable the user to: easily compile and package several applications sharing common libraries without the mess with DLLs use the Global Optimizer for more than one application specify Java system properties and JET Runtime options on the command line run the same executable as both plain application and Windows service The command line syntax of such executables may be an extension of the java launcher command line syntax to allow specifying the main class, VM options, Java system properties, and the arguments of the application itself.
  21. zztop

    Excelsior JET + JNA to get a transparent window

    Jasper, My understanding is that despite the fragile design of the JNA library, the problem you reported has been solved. Please confirm.
  22. zztop

    jvlc and jet

    Have you tried to place jvlc.dll to rt/bin?
  23. zztop

    jvlc and jet

    That's right because you do not have to load it from Java code (JVLC loads it from native code). That's not perfectly legal as files from /rt folder should not be selectively copied. I would recommend you to check how JVLC loads the dll. If it simply calls LoadLibrary("jawt.dll"), that is a hack exploiting the fact that "java.exe" and "jawt.dll" resides in the same folder and Windows (in particular) looks for DLLs in the folder containing the executable which established the process ("java.exe" in case of JRE). A more reliable way would be detecting the JRE home folder and appending the relative path to jawt.dll
  24. David, as I promised I post here the resolution found for the problem. But first comes a short introduction. After compilation and packaging, each Java class appears in the installation package in one of the three forms: 1. compiled (to be directly executed) 2. included in the original bytecode form (to be JIT?ed on demand) 3. both compiled into native code and included in bytecode form You may control these options in the classpath grid on the page Classpath of the JET Control Panel. Why is the third option needed? Well, certain Java components/API implementations were written so that they need their class files at run time. The word ?files? is emphasized on purpose. Literally, the files must exist at run time because certain API code uses open/read/close operations, checks the presence and size of the files, etc. In such cases, the class files actually serve as resource files. That?s why we had to support option 3 in Excelsior JET. For more details, see the JET User?s Guide, chapter ?Application considerations?, section ?Resource packing? Back to resolution of the problem. Open your project with the JET Control Panel and go to the page Classpath. In the ?Pack into exe? column, select the ?As a whole? option for the following jars axis.jar commons-logging-api.jar Then, compile/package the application and the problem will be out. P.S. For versions prior to 6.5, the option was named ?original jar/zip? but we had to rename it to support both ordinary classpath entries and OSGi bundles
×