Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited


Community Reputation

0 Neutral

About sbeckett

  • Rank
  • Birthday 01/01/1
  1. In our profiling of the adaptive heap size parameter, we are checking the memory configuration at various points. It seems that at startup JET goes ahead and sets the max heap size to 3221225472 bytes, which is I believe the max heap size on a 32-bit system. I just wanted to check that we are seeing intended behavior. We certainly haven't seen the allocated heap size actually grow to anything greater than about 1.3GB, so I think everything is fine, but we wanted to make sure.
  2. sbeckett

    properties files not loading on initial launch

    Running from the Jetpack test run appears to work on first launch even on a Win2K machine. I will continue to investigate the installer package to see if the problem lies there.
  3. sbeckett

    properties files not loading on initial launch

    One more piece of information, it appears only to be a problem on Win2K machines. It doesn't happen on WinXP.
  4. We've got a farily large java app we're compiling with JET 4.1 Pro. We're using Jetpack II, single-root third party installer to build the installer image. We're then using an MSI creation util called Advanced Installer to build the full installer suite. We only include the executable and the xjre in the Jetpack builds, which worked fine in the past. We then add in all the DLLs, properties files, and the manual, graphics, etc in the Advanced Installer build. When we install the app and run it the first time, it can't find the log4j.properties file or the foo.properties file we tell it to look for to load system properties. Once the app is closed and relaunched, it finds all the *.properties files just fine, loads and runs log4j, extracts the system properties from the foo.properties file, and all seems well. Why would it be that the application isn't finding the *.properties files on the first launch? I'm trying to run the installer test inside Jetpack II but have run out of time today to complete the test. I'll update this topic tomorrow with my findings.
  5. sbeckett

    runtime error #3(trap) in jet

    We've also run into this problem, and thanks to Dmitry and Alex we determined it was because of some bad behavior on the part of some AWT DLLs, so JNI was to blame. However, it seems that the new JNI handling is causing a lot of these previously benign or at least masked errors to bubble to the surface for a lot of your customers. We would greatly appreciate a way to catch these sorts of exceptions and put our own error dialog in between the cryptic "#3(trap)" error and our end user. We have heard about the DLL hacking idea, and it's just not that workable for us, since the byte length has to be the same. I would recommend putting in some way for your customers to wrap and catch this problem so that their customers never see it. --Sean Bellamax
  6. sbeckett

    JAI and ImageIO support not working

    So now I understand I don't want to use the JET Profile override to use JAI and ImageIO. Instead I just need the jar and dll files in the resource directory when I compile the app?
  7. I have created a natively-compiled package using JET, but when I run the program it complains that it cannot find the JAI and ImageIO classes it needs. I ran the JET setup utility and added a new JET Profile, based on the 1.5.0_04 JDK. I then specificed the four jar files that are added to the JRE JVM by the JAI and ImageIO installers. I then made that the active JET Profile and ran the native compile. When I launch my app, I get these sorts of stack traces: java.lang.RuntimeException: java.lang.NoClassDefFoundError: javax.imageio.ImageIO Perhaps it's because there are DLL files installed by the JAI and ImageIO packages that aren't included in the JET JVM? There appears to be no way to add to the JET JVM the DLLs that those two packages install to JVM_HOME\bin. I assume that's why the compiled executable is choking on finding the classes it needs? Do I need to get the mlib_jai.dll, mlib_jai_mmx.dll, clib_jiio.dll and possibly the checkmmx.exe files into the JET JVM?