Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited


Everything posted by kyt

  1. App server

    That is good news about Tomcat. Are there plans for Glassfish? Thanks
  2. Since that has been brought up... I have run into crashes on startups often (1 crash in about 500-600 startups). But I have managed to reduce the problem to ...an infinitely small one -- I never have seen it since the fix. I never saw such crashes when the application was run as a "byte code". OLD CODE DESCRIPTION: The application's main class uses "invokeLater stuff" to construct and bring up the main form (JFrame) of the application. The constructor of the frame is quite large -- about 1600 lines of code, mainly dealing with Swing. Also, a slow (500 ms) utility "javax.swing.Timer" is started at the end of the constructor (This timer updates some portions of the main frame). So the run() in Runnable invoked in the main class goes something like this: mf = new MF(...); mf.setVisible(true); This is a legitimate way to deal with Swing. Crash: Sometimes, when the compiled application started with the old code, I would see the process start in the system monitor (Linux) or task manager (Windows), but the main form would not show up. If the application was built to show a splash-screen, the splash screen would show and hang forever (the splash-screen was set to close when a form is shown -- Jet feature), but the application process was there (showing in the system monitor). NEW CODE DESCRIPTION: I modified the code. Now there are sleep(20) calls inserted throughout the constructor -- in about 20 places. The utility timer "starting" call is moved out of constructor into run() of the Runnable. So NOW the run() in Runnable invoked in the main class goes something like this (notice sleeps there too): mf = new MF(...); sleep(150); mf.setVisible(true); sleep(150); mf.startTimer(); I use Jet 6.4 Standard on Linux and the other one. JRE 1.6.0_10. Crashes happened on both.
  3. App rarely hangs on startup

    However, most of the objects in my application that are created on startup are global objects, so they are allocated on the heap. Still, I think there is a possibility that memory allocation may have issues in some conditions. Maybe the heap is not growing fast enough sometimes? I noticed, though, that when the "hangs" happened the process was taking 0% CPU and the allocated memory was about 36 Mb. I'm not sure how much of that allocated memory was for the heap. This heap suspicion is just speculation at this point.
  4. App rarely hangs on startup

    No news so far .. just a question: I think this problem may have also be caused by memory allocation issues. If you noticed in settings I allocate objects on Stack. I had the stack size of about 900 K. This seems kind of low for the number of GUI and other objects I have to create on startup. What do you (Jet run time) do when the size of allocated objects reaches the maximum allowed? Thanks
  5. App rarely hangs on startup

    I can't reproduce the problem with my old code. I'm not sure why. It is possible that some bad code was taken out or there were some other code changes that modified the behavior. I will be visiting this issue from time to time. I have set up a test and logging environment specifically to monitor this issue, so may be I will have news someday.
  6. App rarely hangs on startup

    I will also try to reproduce the problem with trial version Desktop Runtime.
  7. App rarely hangs on startup

    Yes, absolutely. The whole application has been checked and rechecked many times to make sure the Swing single thread (EDT) policy is always followed. It looks like the execution is not getting to mf.setVisible(true); This may be caused by some kind of exception in the previous method (the main form constructor). I will try to catch that exception, if it does indeed exist. OK, I will call it a hangcident.
  8. App rarely hangs on startup

    ...under normal (single start) conditions.
  9. App rarely hangs on startup

    Yes. I have to say that the application performs well once it's started. It's a complex system that talks to some devices and updates many Swing components -- it's a multi-threaded thing that can and does get very intense, but it never hangs or crashes. I may some day provide a sample, but at this time I don't see that I can do it -- I can't provide the original (I assume you want the source code) and making a working prototype takes time. To elaborate on the old code description: The main form constructor is very simple but long. It reads a settings file, builds the GUI and starts a simple thread that loads some DLLs and instantiates a file chooser. The DLLs are not used until after the constructor and the "loading" thread are long finished. Do you think there is a chance that the problem can be caused by the amount of code that has to be executed in one take without any sleeps? Also, I noticed that the problem surfaced more often when many application instances were started quickly one after another. No one saw this problem -- not the QA, not the customers -- just me. So I assume it's very rare. I run Ubuntu Linux and XP on the same machine -- Dell Precision with 2G memory and a dual 2.4 GHz Intel CPU. I have never seen this problem one my single core machines. Some Jet settings: -compilewithfixedheap- -gendll- -genstackalloc+ -genstacktrace- -global- -gui- -ignoreclassduplication+ -ignorememberabsence+ -inline+ -jetcpenablemanualsettings+ -splashcloseonawtwindow- -splashcloseonclick- -splashgetfrommanifest- -classabsence=HANDLE -compilerheap=0 -heaplimit=245946856 -inlinelimit=50 -inlinetolimit=250 -jetcplastpage:=PageOptions -jetrt=Classic -jetvmprop=-Djava.library.path:lib -Djet.jit.fast -Djet.gc.heaplimit:245946856
  10. external libs

    Hello, Excelsior compiles in classes from jars specified on the class path. Then JetPack requires ALL external lib jars (with .class files) to be included in the installation package. I think I got it right. So, my question: is there a way NOT to include the external libs (jars with .class files) in the installation package, since they are already compiled in? That would help a lot. Also, when is the next release of Excelsior Jet scheduled? Thanks
  11. external libs

    Can you tell me how strict is this policy? I have been able to recompile the main project and use the old dependent DLL's without problems. Thank you.
  12. JFileChooser

    There is a very bad bug in 1.6.0_3 that makes JFileChooser very very slow. http://bugs.sun.com/view_bug.do?bug_id=6578753 The latest Java still has it. We need it to browse directories. AWT FileDialog works well, but it's not good for directory browsing. Somebody better do something fast. It's important. :'( Excelsior, can you please make sure you will provide a suitable profile when it becomes available? Thanks
  13. Hello. There is a problem with running Jet and JetPack on Linux machines since these utilities use Java. Details: When I enable NVIDIA graphics accelerator driver (Enable the driver: System->Administration->Hardware Drivers, reboot required) on my Ubuntu 8.04, JOptionPane dialogs start to malfunction. You can see this in Jet and JetPack. For example, open your standard edition Jet and try to change GC ratio -- you should see a message box with some text and "OK" button, but very often the box is empty. Screenshot is attached. I just assume Jet uses JOptionPane. I don't know if using java.awt.Dialog will solve this problem. I just reported this bug to Sun. It may take a while for them to fix it.
  14. JFileChooser

    I see that Sun fixed this bug in 1.6.0_11
  15. I see that Sun has fixed this bug in 1.6.0_10
  16. In this case, I can only make judgments about what I see, and what I see is that JOptionPane malfunctions. I will leave it to Sun to figure out what exactly causes the problem.
  17. vote for this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6734185
  18. run_myapp.bat

    Hi, Jet creates a "run_myapp.bat" file with command that looks something like that: "REM SET JETVMPROP=-Djava.library.path:lib -Djet.jit.fast -Djet.gc.heaplimit:198967296 -Djet.gc.ratio:11 ". These options were defined in "myapp.prj" file. Will these options still be followed/set, if I don't use "run_myapp.bat" file to run the application? I can see that "-Djava.library.path" is followed/set without the the .bat file, however, I have to be sure about the rest. Thank you.
  19. run_myapp.bat

    BTW, U3 first copies the files to be executed to the hard drive and then the program is executed. The exe and "rt" directory are/were in my U3 "host" directory, so they are copied to the hard drive together.
  20. run_myapp.bat

    Yes, I did exactly that, but it was a u3-specific installation. However, today (I have prepared everything from scratch) it worked like a few times before -- the problem is not consistent. I can't figure out what happened, but I'm pretty sure that when the problem happened the preparation of the package was the same as you described. I have an uncontrollable desire to blame on Windows, but no evidence to support it. I'll post any information when I get something new.
  21. run_myapp.bat

    Hello, I'm having problems running a Jet-compiled executable from a USB drive (U3 smart) on a machine that does not have Jet installed on -- the exe complains about JET/bin path. I have prepared an installation package using JetPackII and included all the files in the USB. The same package works well when the exe is run from a hard drive on a machine that does not have Jet installed on. Is this a normal behavior on Windows (I just tried Windows so far)? Is this a bug? I really would like to avoid setting PATH (if that can help) and running the exe from run_myapp.bat or other launcher. Thanks a lot.
  22. run_myapp.bat

    Thanks, Snowman ... my DOS ignorance is despicable!!!
  23. external libs

    Is it possible to to slightly modify a .prj file (change outputname and add some jars) save it as "newproject.prj", build a new executable and then run the new executable which loads a DLL that was built with "!uses oldproject.prj" directive? The classes in the DLL are programmatically compatible with both exe-s -- the additional jars do not affect DLL-to-exe interaction. I have tried to do it, but I get this message: "Runtime error #4(trap, xrXTables.mod:180). Please contact Excelsior ..." I don't understand what is going on. Can you help? Thanks
  24. Hello, I don't mean to be annoying, but is there something that is stopping an unauthorized user from replacing your exe? You may try verifying the integrity of your DLL with md5, provided the architecture permits that. But this is a weak security approach -- your verifying exe can still be "edited" by a hacker, although, it may take time to narrow down the location/s in the exe to edit. If you are so concerned, the better way is to encrypt your exe and wrap it up into another exe, so your verifying code would be practically impossible to edit. But you, most likely, have already thought of that.