What CRTJVAPGM does

Remember that AS/400 is an object-oriented system.

What appears to be an ordinary Unix or DOS-style flat-file is
actually a persistent object.  Not a Java object or a C++ object,
but an object created, controlled, and maintained by OS/400.

We exploited this in Java to enable a "covert" program to be
attached to what appears to be an ordinary .class or .zip file.

Thus, CRTJVAPGM creates a real OS/400 program, in a manner
similar to CRTBNDC or CRTRPGPGM, although with some
differences for Java just as there are differences between C and RPG.
On difference is that instead of sticking it in a library as we ordinarily
would, the *PGM is instead "hidden" behind the apparent "flat file".

It is just as real for all of that and you can see what how it was
compiled and so on, if present, with DSPJVAPGM.  The reason
not to make it an ordinary *PGM is to meet the normal expecatations
of Java portability.  It's a unique technology.

A key issue is interoperability.  If you want to have
interpreted code (this is really something no one should do
now, but maybe a few might) and compiled code, the CRTJVAPGM
allows you to mix and match interpreted code, highly optimized
Java code and not so highly optimized java code (e.g. CRTJVAPGM
OPTIMIZE(20)) all in a single, seamless application that operations
just like a Java setup on any other system with the usual mixtures
of .class and .zip files.  It's just that on the '400, there's the added
ability to insert compiled code that no one else has.

When Java on the '400 invokes a new method, its CLASSPATH
search operations are simlar to other architectures.  But, it does one
extra
thing.  If it finds that the .class or the .zip file that it is now
searching
contains the method, it also looks (since it understands OS/400
objects) "behind" the apparent flat file to see if a previous CRTJVAPGM
attached a program to it.  If someone had done so, and the Java
virtual machine is invoked in the usual way, then the attached program
is used instead of interpreting the bytecodes.

If you check around, you'll see literature on the Java Transformer,
which is the formal name for the CRTJVAPGM process.

Starting in V4R5, we also added the more ordinary "just in time"
(JIT) compile process, which creates some on-the-fly compiled
code, but CRTJVAPGM OPTIMIZE(40) produces better
code than the "JIT" process does.  JIT and CRTJVAPGM objects
can interoperate as well.


PS, nearly no one anywhere does much actual interpretation
anymore.  Our competitors use JIT technology of one sort or
another.  About  the only place you'd expect much interpretation
nowadays would be embedded Javas or some other place
where memory is still at a high premium.  Older books and older
web pages will still talk about interpretation, but those references
are now obsolete, though still all too easily found.



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