[700] in java-interest
Re: a dumb native code question
daemon@ATHENA.MIT.EDU (Michael Mills 21728)
Fri Jul 14 15:13:09 1995
From: ekim@nyquist.bellcore.com (Michael Mills 21728)
Date: Thu, 13 Jul 1995 22:51:36 -0400 (EDT)
To: java-interest@java.Eng.Sun.COM
Chris and John,
Thanks, I finally get it. I found this discussion very useful.
I use the Sun Java mail archives to search for answers to questions and I am
afraid that the subject line: java-interest-digest V1 #82 is too cryptic.
I have "combined" the emails in the thread and changed the subject back to:
Re: a dumb native code question. I assume this will help other search the
archive for threads related to native code...
thanks again,
Mike
M = Mike ekim@nyquist.bellcore.com
C = Chris csw@scndprsn.Eng.Sun.COM
J = John johnm@medicus.com
M>There has been some discussion of converting Java bytecode to
M>sparc assembler and to C++. I am a little confused. From looking at the Java
M>white paper I have been under the impression that at some point
M>Java would do this for me on the fly. Does the white paper imply that this
M>will be a standard Java feature?
C>>I think people are working on this issue because they find it
C>>interesting and nothing more. Sun will eventually supply machine code
C>>generators for a few platforms. Frank Yellin has done a lot of
C>>infrastructure in the runtime to allow machine code and interpreted
C>>code to coexist in an application, and he has been generating sparc
C>>machine code for a while now. There are still some integration issues
C>>to be worked out but the performance gain of compiled Java bytecodes,
C>>as noted by Thomas Hickey, is very exciting.
M>>> Is this what is called a "fat binary". Multiple versions of a class
M>>> or a method which have the right binary version picked at runtime?
C>>>>In principle, yes, this would be a fat binary, but I doubt that we will
C>>>>ship around class files with a bunch of different machine code versions
C>>>>in them. All I intended to point out is that the class file format can
C>>>>*potentially* handle multiple architectures. We intend to do on the
C>>>>fly compilation to machine code at runtime as the white paper said.
J>>>>> We need both, me thinks.
C>>It was kind of eerie to see Thomas Hickey's work on generating C-code
C>>from the java bytecodes. Cames Gosling did an experiment like this
C>>called java2c which basically did the same thing. That wasn't put into
C>>the release because it doesn't really work as a Just-In-Time option,
C>>but it's probably fun to do and I wish I'd thought of it.
C>>Keep in mind that we really want to maintain platform independence of
C>>java programs. Frank's changes to the class file format allow machine
C>>code for multiple platforms to co-exist in a single class file. The
C>>virtual machine code, however should never go away because it is the
C>>ultimate recourse if you have a different architecture. Also in the
C>>group here we have viewed machine code generation as fast process that
C>>would be applied only to certain critical classes, after they were
C>>integrated into a running system, hence the just-in-time name.
M>>> I have no expertise in security - but if the class has binary code then
M>>> does this cause a security problem because Java cannot verify the code?
C>>>>Absolutly. Theoretically I suppose you could checksum and sign the
C>>>>compiled code, but it's not worth it. Just do on the flay
C>>>>compilation. You verify the bytecodes and then compile them top
C>>>>machine code. Shipping machine code across the wire is a losing
C>>>>proposition.
J>>>>>Right but only doing just-in-time-compiling from the bytecode precludes
J>>>>>the easy integration of platform specific native code when it's
J>>>>>available.
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
