Jump to content
Excelsior Forums

mhoeffner

Members
  • Content count

    0
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral

About mhoeffner

  • Rank
    Newbie
  • Birthday 01/01/01
  1. JDK 1.5 Update 12 support

    Any idea when JDK 1.5 Update 12 will be supported in JET 5.0? There's nothing specific in update 12 that I'm waiting for but I'm close to a release and I'm wondering if I should wait. Thanks!
  2. Hi. I just upgraded to JET 4.5 and am running into some issues with the size of my distribution. My original install size with JET 3.5 was 4.6 MB. I ported everything to 4.5 which was pretty easy, but now my install size has ballooned to 24 MB when I stick with my original installer product (ClickTeam Install Creator). If I switch to using JET's installer, the size drops from 24 MB to 14 MB. The latter size is a whole lot more acceptable to me. I'm too embarrassed to distribute the product at 20+ MB. I imagine the JET installer is so much smaller because it can use Pack200. I'd like to stick with Install Creator because it is a full-featured installer product that has some features that JET doesn't (such as opening a URL after an uninstall, registering ActiveX components, etc.). Unfortunately it's not Java-centric so it can't use Pack200 internally. I can have it call unpack200.exe though. Any tips on how best to incorporate Pack200 pre-install? What arguments does JETPack pass to pack200 and what files does it use it on other than rt.jar, jsse.jar, and dnsns.jar (which I see temporarily in the tmprtjarsdir directory)? What other optimizations and/or compressions is JETPack using? When I created my own rt.jar.pack.gz, my Install Creator install (that uses zlib and bzip2) got a lot smaller bit it was still 50% bigger than with JETPack. Also, why does rt.jar change in size? In the initial JDK distribution and JET profile, rt.jar is 37,757,974 bytes. After packing and installing (unpacking) it, using the JET installer, it becomes 34,812,071 bytes. If I use my installer product, it's 7 bytes smaller at 34,812,064 bytes. I'm not too interested in the 7 byte difference. I am interested however in why the installed rt.jar is 3 MB smaller than the initial rt.jar. Thanks, Mike
  3. I figured this out. When I ran JETSetup.exe and also viewed jet.config, I found that I was missing the JRE for my 1.3 profile. Reinstalling the JRE to the right directory fixed the problem.
  4. I'm not sure what may have changed on my system (this is actually happening on 2 separate computers), but I'm now getting the following error when I try to run jpiib: J:\JET\bin>jpiib.exe Exception in thread "main" java.lang.UnsatisfiedLinkError: no awt in java.library.path I am still able to run jc.exe succesfully. Any ideas on what may have caused this? This is version 3.5 MP3 with JDK 1.3.1_11. Thanks, Mike
  5. Has anyone had any successful experiences with using executable compressors like ASPack, UPX, and PECompact on JET-compiled apps? I just did some experimenting and found that neither UPX or PECompact worked though I didn't spend much time trying to tweak them. When using their default options, they both led to the error of "Invalid component: no CPB" on launch. ASPack however appeared to work perfectly. Using ASPack 2.12 which is only $49, I was able to trim my disk footprint from 10.6 MB to 3.7 MB. The installer only reduced from 4.2 MB to 3.4 MB due to its own compression but I'll take what I can get. In addition to compressing my compiled .exe I was even able to compress the JET runtime DLLs successfully. Some example numbers: - app.exe - 1,715 kb -> 423 kb - swt.dll (JET-compiled wrapper of swt.jar) - 1,479 kb -> 471 kb - xkrn35039.dll - 3,507 kb -> 1,250 kb - xl5235039.dll - 401 kb -> 92 kb - xsrs35039.dll - 231 kb -> 92 kb I imagine that there are minor performance delays at startup but are there any JET-specific issues that I should be concerned about, especially issues related to stability and memory? Thanks!
  6. [This is for a JRE-less app produced with JET 3.5 MP3 Pro.] In the process of migrating my app from JDK 1.3.1_11 to 1.4.2_04 without any code changes, my app now requires 11 runtime DLLs instead of 2 (xkrn and xsrs). I believe that this is related to my use of JSSE which became bundled in JDK 1.4. I'd like to know if there's a tool that I can use or a flag that I can set that will help me figure out why my app needs additional DLLs just as JetPackII discovers during trial runs. For instance, I'd like to find out what classes that I'm using from JSSE that cause xawt.dll to be required. With that info I can search for workarounds that might allow me to remove the dependencies on those DLLs. One example of a workaround in another app using JDK 1.4 was switching from using java.security.SecureRandom to java.util.Random. This one switch allowed me to get rid of 9 DLLs. Unfortunately the only way that I was able to do it was though trial and error. I just deleted the DLLs that weren't need with it earlier under JDK 1.3 and then figured out where my code would die. Thanks.
  7. I'm having a large group of users test my JET-compiled app and many are receiving the following error message: "Uncaught exception: Out of memory" But they don't see it just once. One user reported that it popped up 200 times and another said 38. I haven't found any pattern to this yet, including when it occurs or the operating system. These users have plenty of RAM installed which eliminates the obvious cause. The application rests using about 25 MB of RAM and peaks at about 33 MB (as seen in the "Mem Usage" column of task manager.) When run without JET, the memory usage is similar. I am using all of the default options: heap-size is adaptive and stack limit is 878.9k. Other config info: - JET Pro 3.5 MP3 - JDK 1.3.1_11 - No JetPerfect - JRE-less Some questions: - Is there a way to prevent the error message from occuring over and over? I've just lost a potential customer if they have to close 200 error messages! - Should I change the default memory options? If so, is there any way to determine what optimal or at least reasonable values would be? Is there a way to profile the application using JET to give me some hints? - Is there a way to get the JET-compiled app to log information such as memory usage and possibly a stack trace when this error occurs? It may already do so, but my users are not tech savvy so it's hard to ask them to look around for a log file when I don't know what it's called. - Can these values be set at run-time so that I can ask a user to change a properties file if they run into problems? Thanks for any suggestions, Mike P.S. If you can, please update the "Max Age since last post" default on the forums search page. Having it set to 7 days doesn't make much sense when there's so little traffic on the forums.
  8. "JET RT" DLLs with recompiled executables

    When you say "new executable", I assume that you mean an updated executable (a recompiled version of one that was already installed.) If so, excellent. That's what I had been doing and was hoping to continue doing. It seemed to be working fine until just one time when the "Unable to find/load XKRN353039.DLL" error occurred. I'm guessing now that I probably just made a stupid mistake and copied a file incorrectly. Last related question: Do I actually need to create a whole new .jpn with the same settings or can I just use the same .jpn? Thanks again for your help!
  9. "JET RT" DLLs with recompiled executables

    If I can get around using xbind, should I still run the executables through an 'update' package? Does JetPack alter them in any way or does it just copy them and create the appropriate xbind script? The file sizes and timestamps on the executables don't appear to change.
  10. "JET RT" DLLs with recompiled executables

    Here's a quote from Knowledge Base Article 17 (http://www.excelsior-usa.com/kb/000017.html): My executables are JRE-less but I am not using JetPerfect. ?My installation is single root. ?The executables may be in different directories based on where they are installed by the user, but the JET RT DLLs are always the same two (krn and srs) and they always reside in the "JET RT" directory where the executables are. ?For example: C:\dir\foo.exe C:\dir\bar.exe C:\dir\JET RT\xkrn35039.dll C:\dir\JET RT\xsrs35039.dll It is necessary for me to mess with xbind? ?I'm not looking forward to the messy process of having to code my self-updating application to create xbind redirection scripts... Not using an updateable package in JetPack has worked for me on all but one occasion, but the problem may have been due to another mistake that I made. ?I just want to make sure that not using an updateable package should work in this very specific scenario. Thanks for your time.
  11. Config: - JET Pro 3.5 MP3 - JDK 1.3.1_11 - No JetPerfect - JRE-less - Third party installer with single root I have multiple JET-compiled executables and DLLs that I am distributing which reside in the same directory. ?Within that directory, JetPack produces "JET RT/xkrn35039.dll" and "JET RT/xsrs35039.dll". ?If I recompile an executable with the same JRE, do I need to redistribute the files in the "JET RT" directory? ?The "JET RT" DLLs always seem to have the file size and timestamp and I'm assuming that JetPack just copies them from JET\bin. Unfortunately I have encountered occasional problems with redistributing the freshly compiled executable and not the JET DLLs. ?The error is "Unable to find/load XKRN353039.DLL (referenced from C:\...\foo.exe)". ?This occurs when "JET RT\xkrn35039.dll" is clearly in the same directory as foo.exe. ?Could this have something to do with the case of the filename (the error message is all caps)? ?Or could it be that for some reason foo.exe didn't know to look in the "JET RT" directory. ?Should I add the JET RT directory using -Djava.library.path? ?This problem didn't occur on the computer that has JET installed, but that was probably because xkrn35039.dll was in my PATH in JET\bin. Hopefully this isn't overly confusing. ?Basically I guess I just need to know if JetPack makes any changes to the compiled executables/DLLs or to the xABC12345.DLLs. ?It appears to just copy them over but that doesn't explain the missing DLL problem. ?If I have multiple EXEs, can I just recompile one of them and redistribute it? Also, this isn't directly related, but is there a way that I can force JetPack to include xsrs35039.dll in my distribution? ?The only way that I can get it included now is by doing a trial run every time.
  12. I'm trying to squeeze every last byte out of my install so I tried performing bytecode obfuscation on my jars using RetroGuard (http://www.retrologic.com/retroguard-main.html). The jar sizes decreased by a small amount, but the compiled JRE-less .exe actually *increased* in size by a tiny amount. The obfuscation that I did wasn't very aggressive, but I was surprised when the end result was actually larger. Am I wasting my time trying to obfuscate the jars? Does JET already optimize field, method, class, and package names? Thanks.
  13. Anyone using JACOB bridge with JET?

    The only problem that I had was with IE events being ignored when I used DispatchEvents. For my usage, the following combination of products is working great: - JET 3.5 MP3 (I need MP3 since a required fix was made post MP2) - JDK 1.3.1_011 (1.3.1_06 also worked) - JACOB 1.7 patched with jacod17_jre142fix_bin_2003-10-15_br.zip in the jacob-project group at Yahoo Groups.
  14. Sharing compiled SWT DLL amongst EXEs

    Thanks. Adding the sym and bod lookups to the project file worked. And wow! Doing this for SWT and JSSE reduced my total file size by about 35% and my compile time by about 80%.
  15. I have multiple JRE-less executables that use SWT. I would like to compile swt.jar into a DLL that is shared amongst the EXEs (to improve the install size in addition to hopefully the compile time.) I am not using JET Perfect and I'm using the following versions of products: JET Pro 3.5 MP3 JDK 1.3.1_06 SWT 3.0 M7 (3038) My first step was to create SWTWrapper.DLL. I created a DLL project for swt.jar and forced the whole jar into the project. I then "unforced" the package org.eclipse.swt.awt so as to remain JRE-less. Below are the contents of the project file: %%Excelsior JET v3.50 project file -gcdefragment- -genasserts- -gendll+ -genstackalloc+ -gui- -ignoreclassduplication- -ignorememberabsence- -inline+ -classabsence=ERR -compilerheap=0 -heaplimit=0 -inlinelimit=100 -inlinetolimit=1000 -jetvmprop=-Djet.gc.heaplimit:0 -stacklimit=900000 -lookup=*.class=./swt.jar; !push -bindresources+ -resourceonly+ !module ./swt.jar !pop !module org/eclipse/swt/SWT.class !module org/eclipse/swt/SWTError.class !module org/eclipse/swt/SWTException.class !batch *.class "org/eclipse/swt/graphics" !batch *.class "org/eclipse/swt/internal" !batch *.class "org/eclipse/swt/widgets" !batch *.class "org/eclipse/swt/events" !batch *.class "org/eclipse/swt/layout" !batch *.class "org/eclipse/swt/ole" !batch *.class "org/eclipse/swt/accessibility" !batch *.class "org/eclipse/swt/dnd" !batch *.class "org/eclipse/swt/printing" !batch *.class "org/eclipse/swt/program" !batch *.class "org/eclipse/swt/custom" !batch *.class "org/eclipse/swt/browser" I then took an EXE project that formerly compiled swt.jar and removed swt.jar using the GUI. I then closed the GUI and manually added the following line to the project file: !module SWTWrapper.dll When I compiled the updated project using a batch file, I received a bunch of warnings but a tiny 10 kb .exe was produced. The code for this .exe was only 20 or so lines of code, so without SWT that didn't seem impossible. Here's the list of warnings that were displayed at the end: List of absent classes: org/eclipse/swt/graphics/Image org/eclipse/swt/widgets/Composite org/eclipse/swt/widgets/Display org/eclipse/swt/widgets/Label org/eclipse/swt/widgets/Shell List of not verifiable classes: Main: throws NoClassDefFoundError: org/eclipse/swt/widgets/Composite ------------------------------------------------------------------- files: 1 errors: 0 warnings: 7 notices: 0 When I ran the tiny 10kb .exe that was generated (note that SWTWrapper.dll and swt-win32-3038.dll were in the same directory), I got the error: Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/swt/widgets/Composite When I used JetPack and included the 2 SWT DLLs, I received the same error from both the trial run and the resulting executable. Compiling SWT into a reusable DLL seems like it would be a common situation. Has anyone else done this successfully?
×