[697] in java-interest
Re: java-interest-digest V1 #82
daemon@ATHENA.MIT.EDU (Michael Mills 21728)
Thu Jul 13 19:06:01 1995
From: ekim@nyquist.bellcore.com (Michael Mills 21728)
To: csw@scndprsn.Eng.Sun.COM (Chris Warth)
Date: Thu, 13 Jul 1995 18:02:43 -0400 (EDT)
Cc: java-interest@java.sun.com
In-Reply-To: <9507131644.AA14232@builder.Eng.Sun.COM> from "Chris Warth" at Jul 13, 95 09:44:09 am
Chris,
Thanks for the detailed reply. I think I am still a little confused.
[stuff deleted]
> Keep in mind that we really want to maintain platform independence of
> java programs. Frank's changes to the class file format allow machine
> code for multiple platforms to co-exist in a single class file.
Is this what is called a "fat binary". Multiple versions of a class
or a method which have the right binary version picked at runtime?
> The
> virtual machine code, however should never go away because it is the
> ultimate recourse if you have a different architecture.
I thought that having a Java runtime would imply at some point a builtin
method of generating native code from bytecode. This conversion would
happen at the client(or at runtime). This way, if I have a compute intensive
class, I do not have to make a new version for different architectures.
I have no expertise in security - but if the class has binary code then
does this cause a security problem because Java cannot verify the code?
> Also in the
> group here we have viewed machine code generation as fast process that
> would be applied only to certain critical classes, after they were
> integrated into a running system, hence the just-in-time name.
Does this basically mean 1) code and debug using bytecode 2) Profile and only
make code native when it is really necessary?
Thanks,
Mike
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
