RE: Preferred method to access databases from Servlets

Eric wrote (of static compilers for Java and why there aren't
many):

>I am aware of only a few that are
>still an active project. Ibm has the hpj, symantec has
>its compiler, tower produces one as well. You would
>think that there would be more. I could be that the
>JIT makes this unneeded, but there would be some
>benefit in makeing full blown compiled code and
>incuring the compile time only once.

The JIT does make this less necessary for reasons I have already
give.  But, there's more to it than that.

The main reason is that a traditional static compile either stretches
or outright breaks a few of Java's rules.  This limits the appeal of
static compilation.

In particular, Java wanted to be extremely network friendly and permit
bytecodes (e.g. applets) to be freely downloaded across the network.
It also wanted the bytecodes not to be downloaded until needed if
that's what was wanted by the application/applet/servlet designer.

A direct consequence of this strategy is that you might begin execution
with a child class that is not present, but its parent is and then later
ask for the child class.  You can achieve
this effect somewhat with DLLs in C++ (C++ *SRVPGM  in OS/400),
but there are subtleties that make Java even more
dyamic than regular DLL linkage.  In particular, it is possible
(in principle and sometimes in practice) to load _all_ the DLLs you require
at the very beginning of executing a program.  This means they all
have to be there whether you use them or not.  Java explicitly does _not_
require this in theory or in practice.

In many real-world cases (especially a more traditional application
that you probably have in mind) running under what amounts to DLL/EXE
rules does not burden a Java application.  This is why there can be
static compilers out there to begin with.  The designer agrees, in
effect, to have everything present at compile time, just as usual, and
forgo some dynamic capability.  For those of us who want to write
true applications, this is not normally a burden; we'd tend to do this
automatically.  But, for other uses of Java, this is more of a
problem (e.g. some kinds of JSPs, perhaps).  Here, you might be
producing Java code "on the fly" either as bytecodes or as source
that gets compiled (a la JSPs).

Java actually controls this through their compliance suite.  To be able
to say you are Java compliant, you have to fulfill a great many subtle
rules
about allowing dynamic class loading.  One of the many remarkable
feats of the AS/400 Java Transformer team was doing a
something very much like a static compile while still achieving
full compliance.

This was not easy.  If you look carefully, I suspect
you'll find products like Symantec only claim full compliance when
running in their regular JIT mode and not in the compile mode.

It's been a while, but when I read the web pages of the static
compile products, the ones I remember had a pretty prominent
disclaimer pointing out what I say above, if more concisely and
more discretely.

It's the sort of thing that a heavy Java gear head / compiler
writer will know, but an ordinary application writer will get right when
doing an application, kind of reflexivley, and not read the
fine print.  Yet, that same coder will also
use the regular, official, fully dynamic Java rules when writing
servlets and JSPs.  This is kind of cool, really, even
if the Java purists don't like it much.  They think everyone
should be fully dynamic all the time.

But, best of all, when doing OS/400 Java, it's easier still,
because all our code is complaint and you don't have to
know all this stuff (except for the fun of it).



Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
                          Dept HP4, Rochester MN
--


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---