Jet Version 4.0 is out

Discussion in 'Java' started by Roedy Green, Sep 30, 2005.

  1. Roedy Green

    Roedy Green Guest

    JET is an AOT (Ahead Of Time) optimising compiler. I use it for nearly
    everything I run on my own machines. Excelsior came out with Jet
    Version 4 today.

    This marks some big changes precipitated with a new legal agreement
    with Sun. Some of the changes are good, some distressing.


    The good news your compiled apps no longer need a Sun JRE installed.
    The bad news is you can no longer distribute self-contained
    executables. You must distribute the ENTIRE JRE in compiled DLL form
    along with your app!! Phht! Why Sun insists on that makes no sense to
    me. I can see them demanding no stripped down JRE, but what difference
    does it make if proprietary complied equivalents are stripped down?

    The other good news in the compiler now meets Sun's validation suite
    for compatibility. I never had troubles with compatibility, but is
    nice know that is nailed even better.

    Pricing is in flux. My website entry is a bit out of date at I will be updating it in the next
    few days with information they sent me.

    The big advantage of Jet over java.exe is apps start up a lot faster
    and I can start them with a simple exe name. It makes my apps easier
    to use as command line utilities.

    The biggest disadvantage of Jet is you must exactly match DLL with
    app. You can't run old code on a new DLL runtime without a recompile.

    So roughly you convert every app and every customer at once to the new
    compiler version. Keeping old compiled code around creates headaches.
    Roedy Green, Sep 30, 2005
    1. Advertisements

  2. Roedy Green

    ldv Guest

    I believe this is a standard requirement of the Sun's J2SE technology
    license and no other vendor (IBM, BEA, Apple, etc.) has previously
    asked for a change. Excelsior promises to continue negotiations with
    Sun in order to resolve this problem and asks for real-world cases to
    back their position:;action=display;num=1119552645

    Excelsior also mentioned they have ideas for moderate download size
    reduction that do not break the license they have now.

    ldv, Sep 30, 2005
    1. Advertisements

  3. Roedy Green

    Roedy Green Guest

    Due to the Sun license, partial redistribution of JRE is prohibited

    Fine. but what Jet is redistributing is not the JRE, it is an omnibus
    *.DLL program that contains a lot of the JRE code in compiled form.
    It has no java.exe, no *.jars.. It can't in any way impact Sun
    customers or be confused with a JRE.
    Perhaps a lawyer could argue the DLL is effectively a sample program
    the demonstrates each the JRE methods, but that does not make the same
    as the JRE.

    Another lawyer might argue that Sun needs to define the JRE. It
    consists of source, rj.jar java.exe etc. The thing Jet wants to
    distribute has a similar function, but has none of those elements.

    Another lawyer might argue the common sense case. WHY is this
    restriction there? Sun obviously sensibly does not want anyone
    distributing partial JREs. These will cause other unrelated apps to
    fail causing headaches for users, Sun and other Sun customers. What
    Jet wants to do has no such problem. Has Sun any other reason for the
    Roedy Green, Sep 30, 2005
  4. Roedy Green

    ldv Guest

    This does not have to do anything with lawyers.

    1. A Java program can load any Java platform API class. Just call
    class.forName(argv[0]) in your main() method and you are all set.

    2. Suppose there is a class A in the Java platform API that uses
    reflection or has a native method. You cannot guarantee that it will
    never load another class B. Now, run "java -verbose HelloWorld" and
    you'll see how many API classes and internal JRE classes are loaded for
    what looks like a trivial program. Some of them use reflection and many
    of them have native methods.

    So unfortunately it is not possible to safely approximate a Java API
    subset sufficient for the given program to work. Therefore a compatible
    Java implementation must include all Java API classes with any program.

    What Excelsior JET could do is let you explicitly remove parts of the
    Java API that you think your program will never use and bear full
    responsibility for that. Imagine a third-party library bringing up an
    AWT dialog if it cannot find its property file when you start your
    server (I have seen this behavior in a server-side app developed by our
    client.) But Excelsior needs to obtain Sun's permission first.

    ldv, Sep 30, 2005
  5. Roedy Green

    Roedy Green Guest

    I forgot it could do that. I have always bundled all my dynamically
    loaded classes at compile time. And with JetPerfect I could get a
    list of the classes it would dynamically load as it ran. But that is

    The nice thing from the developer's point of view is you don't have to
    decide which encodings and locales to support. They will all be

    The good news is you might be able to split your app into two parts --
    the run time and your app proper. The runtime need be only installed
    once, not once with every app or every update.

    Even if Jet had a separate runtime for each app, with stuff pruned out
    for sure it would never use (perhaps decide with programmer help),
    that still is no concern of Sun's. Jet might not want to do that to
    require max one copy of the run time, or to reduce headaches caused by
    mising code, but it is not really anything to do with Sun.

    One thing Jet needs is a way of pruning out old runtimes no longer
    used without requiring a clever person.
    Roedy Green, Sep 30, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.