Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited


Posts posted by mhoeffner

  1. 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.



  2. 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:


    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.



  3. 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?


  4. [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.


  5. 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,


    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.

  6. 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!

  7. If you want your new executable to reuse the already-installed JET RT DLLs, you must create an 'update' package adding that executable.

    Here's a quote from Knowledge Base Article 17 (http://www.excelsior-usa.com/kb/000017.html):

    To summarize, if you have created a JRE-independent executable using JetPerfect, the installation process can be as simple as just copying the application to the target system. If that is not the case, additional files have to be copied and executable patching may be required.

    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\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.

  8. 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.

  9. 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?


  10. 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.

  11. 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
    !module ./swt.jar
    !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:
    List of not verifiable classes:
           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?

  12. Are any other JET users using JACOB ("The JACOB Project: A JAva-COM Bridge" at http://www.danadler.com/jacob/index.html)?

    I've having a problem with Internet Explorer events being raised after I compile with JET 3.5, though it's fine when run through java.exe.  I just opened a support ticket but I wanted to see if anyone else was using JACOB before I spent time posting the details here.



  13. Hi.  I am currently evaluating JET Professional solely for the ability to build a JRE-less and therefore small installation.

    I've run into a problem with reducing the number of dependencies for a very simple program (see code below) that uses HTTPS/SSL.  Note that this is with JDK 1.4.2.

    If I only include XKRN, the following exception is generated:

    java.net.MalformedURLException: unknown protocol: https

    If I include XKRN, XJCE and XSSE (which will automatically add XSEC), the following exception is generated:

    java.net.SocketException: Default SSL context init failed: jks not found

    If I do a trial run, JetPack chooses XAWT, XCRB, XJCE, XKRN, XMIA, KMIS, XRMI, XSEC, XSND, XSQL, and XSSE.  This application functions correctly in this case.  Unfortunately including all of these DLLs defeats my goal of producing a small installation.  I can't imagine that most of these are needed.  Do you have any suggestions for how I can reduce the tangled dependencies?  This works fine on the development machine with just XKRN, but I'm assuming that's due to the JDK and/or JET installation.

    I'm going to try using JDK 1.3.1 with JSSE to see if that helps.

    Here's very simple code that will generate the above exceptions:

    import java.io.*;
    import java.net.*;
    public class HelloSSL
         public static void main(String[] args) throws Exception
                     PrintWriter writer =
                           new PrintWriter(new FileWriter("google-secure.html", false));
                     URLConnection conn =
                           new URL("https://adwords.google.com/select/").openConnection();
                     BufferedReader in =
                           new BufferedReader(
                                 new InputStreamReader(conn.getInputStream()));
                     String line = null;
                     while ((line = in.readLine()) != null)
               catch (Exception ex)
                     PrintWriter writer =
                           new PrintWriter(
                                 new FileWriter(
                                       "exception-" + System.currentTimeMillis() + ".txt",
                     StringWriter sw = new StringWriter();
                     ex.printStackTrace(new PrintWriter(sw));