Jet Version 4.0 is out

Thread view:

Roedy Green - 30 Sep 2005 03:22 GMT

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.

See
http://www.excelsior-usa.com/jetlatest.html?ml=jet400

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
http://mindprod.com/jgloss/jet.html 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.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Reply to this Message

ldv@mail.com - 30 Sep 2005 08:03 GMT

> 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
[quoted text clipped - 12 lines]
> me. I can see them demanding no stripped down JRE, but what difference
> does it make if proprietary complied equivalents are stripped down?

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:

http://www.excelsior-usa.com/cgi-bin/yabb/YaBB.cgi?board=JET;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

Reply to this Message

Roedy Green - 30 Sep 2005 08:38 GMT

>http://www.excelsior-usa.com/cgi-bin/yabb/YaBB.cgi?board=JET;action=display;num=
1119552645

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
restriction?

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Reply to this Message

ldv@mail.com - 30 Sep 2005 13:02 GMT

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

> >http://www.excelsior-usa.com/cgi-bin/yabb/YaBB.cgi?board=JET;action=display;num=
1119552645
>
[quoted text clipped - 23 lines]
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Again taking new Java programming contracts.

Reply to this Message

Roedy Green - 30 Sep 2005 20:30 GMT

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

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

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

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.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Reply to this Message

Jet Version 4.0 is out

Free Magazines