Denis, Thanks for the excellent argumentation. I basically concur with you.
I'd like to reply to a few arguments, though: 1. Today's JVMs offer the option to have the byte code compiled on the fly when certain conditions are met. So, these JVMs already have the capability to run "machine code" instead of "byte code". This is the runtime environment you'd need to run Java code that has been compiled at the will of the programmer instead of at the will of the JVM. All you need is an option to tell the JVM where to find and/or how to recognize pre-compiled java class files. No need for a new runtime environment, no need for application programmers to care any more about memory management as they need to care about with today's Java environment. You still instantiate a JVM and tell it which Java class file to run. BTW, programmer's don't need to care about memory management in other HLL languages, do they? It's the HLL's runtime that manages this. 2. Why do you think that compiled Java class code needs to fill PDSs? The JVM does *not* create PDS members when the JIT compiles byte code into machine code on the fly, right? It stores the machine code in some JVM maintained cache. Use the UNIX file system instead of the cache for the pre-compiled programs. Let the JVM search the UNIX file system in addition to the cache to find compiled versions of class files. 3. Do you test your application in the byte code version as well as in the JIT compiled machine code version today? If so, there isn't any more testing to do than you already do today. If not, why do you trust the JIT to produce machine code exactly equivalent to the byte code and would not trust the compile done in advance to produce the same reliable code? I'd expect this to be the very same version of the compiler, namely the JIT compiler. Regarding the Java releases coming out very frequently: The built in JIT is already at the correct level for each Java release. As I mentioned before using this as the standalone compiler eliminates the need for another compiler to be kept up to date. 4. Regarding a "pure Java processor": How would you implement the different versions and levels of today's JVMs into one physical processor? One "chip" per version and modification level? Being serious -- I think it is not currently practically doable; Java is still being developed and extended to much. 5. zAAPs. JIT compiled Java code can still be offloaded to zAAPs, can't it. Why would this not apply to pre-compiled code being executed in the same runtime environment together with byte code and JIT machine code? -- Peter Hunkeler CREDIT SUISSE ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
