Python bytecode
Roi Katz
Hello,
I am new to Python, and having found no answer in its various text
references, I ask: would it compromise Python's dynamic typecasting if
Python compiled down into the same bytecodes or bytecode format as
does Java? Are there implementations of Python which do this (I
personally find little value in this, but it would be an excellent way
to keep compatibility with VM's and such).
Thanks,
Roi Katz
ik...@erols.com
Fredrik Lundh
> I am new to Python, and having found no answer in its various text
> references, I ask: would it compromise Python's dynamic typecasting if
> Python compiled down into the same bytecodes or bytecode format as
> does Java?
Not necessarily, but it may hurt performance quite a bit. You can
check the recent newsgroup discussions on this topic via the locator:
http://www.python.org/locator (use the newsgroup search)
Cheers /F (http://hem1.passagen.se/eff)
aaron watters
From: ik...@erols.com (Roi Katz)
>Hello,
>I am new to Python, and having found no answer in its various text
>references, I ask: would it compromise Python's dynamic typecasting if
>Python compiled down into the same bytecodes or bytecode format as
No. I would judge that this is not really possible, since the semantics
of the two languages are so different (multiple inheritance, dynamic
attributes, keyword arguments, eval - all missing in java).
What is possible is an implementation of Python in Java, and the
merits of this idea have been debated at length recently.
[Frighteningly enough Jim Hugunin threatened to do it :(, which
is scary, because Jim H. has a tendancy to make good on such
threats!]
Alternatively you could have a Python-subset that compiles to java
byte code - not too compelling.
The best option, to my mind is a java/python integration via general
remote object protocols (ala ILU or COM/DCOM) which both seem
to be feasible now (or rsn). The only problem with this is that it
wouldn't fit in with the "pure java" or (as I think of it) the "java java
java java yada yada yada yada" effort. The jury is deliberating.
Aaron Watters
=-=
Eat the best grasshoppers at "La Casa de la Abuela",
Oaxaca, Mexico, off the Zocalo.
Greg Stein
Actually, Aaron's point about it probably not being possible is true,
but for different reasons. The Java VM requires some really strict
adherence to some security rules for how the bytecodes are used in a
program. More specifically, because of those security rules, it is
practically impossible for *anything* besides Java to compile to its VM
and pass the security checks.
It is a much wider problem that simply Python to the JVM. This affects
any language that wants to target that VM.
-g
Steven D. Majewski
_On Mon, 28 Apr 1997, aaron watters wrote:
> From: ik...@erols.com (Roi Katz) >Hello, >I am new to Python, and
> having found no answer in its various text >references, I ask: would it
> compromise Python's dynamic typecasting if >Python compiled down into
> the same bytecodes or bytecode format as >does Java?...
>
> No. I would judge that this is not really possible, since the semantics
> of the two languages are so different (multiple inheritance, dynamic
> attributes, keyword arguments, eval - all missing in java).
>
Aaron: I *KNOW* you know there's no reason Python or other languages
can't be compiled onto the Java VM. There is less of a semantic gap
between JVM byte codes and Python than there is between Pentium
machine codes and Python.
Maybe you meant it can't be done efficiently ?
I don't know -- the jury is still out on this.
Or maybe you were thinking of security problems ( like Greg mentioned ).
Well - that may be true but it only mecessarily applies to applets.
Besides various experiments in Lisp/Scheme, Basic, ADA, etc.
<http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html>
I even see someone doing a version of Forth based on the Java VM:
<http://www.mistybeach.com/Forth/JavaForth.html>
which seem to me even more of a reach than Python.
---| Steven D. Majewski (804-982-0831) <sd...@Virginia.EDU> |---
---| Department of Molecular Physiology and Biological Physics |---
---| University of Virginia Health Sciences Center |---
---| P.O. Box 10011 Charlottesville, VA 22906-0011 |---
By doing just a little every day, you can gradually
let the task completely overwhelm you.
Guido van Rossum
> Aaron: I *KNOW* you know there's no reason Python or other languages
> can't be compiled onto the Java VM. There is less of a semantic gap
> between JVM byte codes and Python than there is between Pentium
> machine codes and Python.
>
> Maybe you meant it can't be done efficiently ?
> I don't know -- the jury is still out on this.
>
> Or maybe you were thinking of security problems ( like Greg mentioned ).
> Well - that may be true but it only mecessarily applies to applets.
In Aaron's defense: usually, when the question "can Python be compiled
to Java VM bytecode" is asked, the asker has heard all the hype about
Java's portability by using a universal bytecode, and has heard that
Python also compiles to some bytecode. Moreover, the asker believes
that there is a problem with Python either being less portable than
Java (not true), or slower than Java (depends completely on what
you're doing). So the asker assumes a solution for the perceived
problem can be found in the fact that both Python and Java use
"bytecode" (as opposed to "machine code").
In fact, JVM bytecode is much closer to machine code than to Python
bytecode. Note that this is not in contradiction with your statement.
I would draw the semantic distance between PVM (Python bytecode), JVM
and Pentium (or any other current general-purpose 32-bit CPU) machine
codes as follows:
PVM JVM Pentium
+------------------------------------------------------+--------+
In other words, compiling Python to JVM isn't considerably easier than
compiling Python to Pentium machine code.
Point in case: in PVM, there is only one ADD instruction, and it is
completely polymorphic. ADD applies to class instances, strings, and
various types of numbers alike -- the switch to the per-type operation
is part of the VM. On the other hand, in JVM and Pentium machine
code, there are separate add instructions for integers, long ints,
floats, and doubles, and so the compiler must know the type of the
arguments if it is to emit the right opcode. (For string+string in
Jave, I presume the compiler emits a subroutine call, much like a C++
compiler would for an overloaded '+' operator.)
Another way to look at it is this: from the Python VM's point of view,
Python only has one data type -- "reference to object". The JVM, on
the other hand, makes assumptions about what kind of object is in a
register or stack entry (and part of the JVM bytecode verifyer is
concerned with making sure that these types are not mixed up).
BTW, Jamie Zawinski's defense of Emacs Lisp as a compiled language is
similarly besides the point. According to his definition Python is
also a compiled language. Fine. I don't care. And as someone else
said, there are no interpreted or compiled languages -- there are only
interpreters and compilers. In Python's case, there's a compiler that
compilers to a very-high-level bytecode VM, and an interpreter for
that VM. Python-on-a-chip is not a feasible solution (yet).
Java-on-a-chip might be. It is certainly much closer to the current
hardware model...
--Guido van Rossum (home page: http://www.python.org/~guido/)
aaron watters
Steve M:
>Aaron: I *KNOW* you know there's no reason Python or other languages
>can't be compiled onto the Java VM.
Steve, I'm flattered, but you overestimate me. My feeling
was that a "compilation" of Python (as currently defined)
to JVM would essentially require a reimplementation of
most of the Python runtime system in Java, but I may be simply
wrong on this, since I admit that I haven't studied it as
closely as I could. It's also possible that we are using the
same words to mean different things. I'd be very happy
and interested to be corrected.
Aaron Watters
=-=
"I mean what I say, or I say what I mean, which
is the same thing you know"
"It's not the same thing at all! Why you might
just as well say that I like what I get is the same
as I get what I like!" -- from Alice in Wonderland.
Tim Peters
> Steve M:
>Aaron: I *KNOW* you know there's no reason Python or
>other languages can't be compiled onto the Java VM.
> [aaron watters]
> Steve, I'm flattered, but you overestimate me.
Oh no! If I see one more msg containing "Turing-complete" on this newgroup,
I'm sorry, but the author dies. Well, I guess they will anyway, so forget
that <wink>.
> My feeling was that a "compilation" of Python (as currently
> defined) to JVM would essentially require a reimplementation
> of most of the Python runtime system in Java,
Ya, I can picture it as an endless sequence of calls to "python_vm" with
three-byte opcode arguments ...
> it I may be simply wrong on this, since I admit that I haven't
> studied it as closely as I could. It's also possible that we are
> using the same words to mean different things.
Ah! That's it. When Steve says "Python", he usually means Spike Jones, and
when he says "Java VM" I think he means the soundtrack to "Lost Highway".
apologetically y'rs - tim
Tim Peters tim...@msn.com, t...@dragonsys.com
not speaking for Dragon Systems Inc.
Jeremy Hylton
Guido van Rossum <gu...@CNRI.Reston.VA.US> writes:
> Java-on-a-chip might be. It is certainly much closer to the current
> hardware model...
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
Strangely enough I saw just such a beast at the grocery store last
night. Starbucks sells Javachip. (It's ice cream, but that shouldn't
be an obstacle for the Java marketing people.)
Jeremy
Steven D. Majewski
On Tue, 29 Apr 1997, aaron watters wrote:
> Steve M:
> >Aaron: I *KNOW* you know there's no reason Python or other languages
> >can't be compiled onto the Java VM.
>
> Steve, I'm flattered, but you overestimate me. My feeling
> was that a "compilation" of Python (as currently defined)
> to JVM would essentially require a reimplementation of
> most of the Python runtime system in Java, [ ... ]
That's not how I read your "impossible", which is why I thought
that either you mispoke or I misunderstood. If you're saying
that the effort may not be worth the gain, that's what I said
the first time this thread came up. What's changed in the
last year has been my estimate of some of the secondary gains
due to what I think is the reasonable (but arguable) belief that
Java:
(1) will largely replace C++ [& C] as an application programming language.
(2) will provide a higher level of portability than is now common
with C + standard posix libraries.
I don't think I'm overestimating you, Aaron. You're too opinionated
to be NEVER wrong, but you've never been absurdly wrong before, which
is why I assumed there must be a communication problem.
> It's also possible that we are using the
> same words to mean different things. I'd be very happy
> and interested to be corrected.
>
> Aaron Watters
>
> =-=
> "I mean what I say, or I say what I mean, which
> is the same thing you know"
> "It's not the same thing at all! Why you might
> just as well say that I like what I get is the same
> as I get what I like!" -- from Alice in Wonderland.
>
Ahh! I see -- you're using Dodgsonian Logic on me!
BTW: I know Guido is never wrong, but that's a matter of theology --
like the way the Pope is never wrong. And I know I've been wrong,
because Guido and Tim have told me so. But has anyone ever seen Tim
be wrong ? Veery Strange .... I've spoken to him on the phone a
couple of times, and, now that I think of it, he DID sort of sound
like his answering machine. And whatever happened to all those
leftover KSR supercomputers after they closed up shop ? You don't
think that maybe during his absence from the list, he cobbled up
an AI simulation of himself in his basement on a couple of KSR's
he swiped when they stiffed him on his severance pay ? Hmmm.
And, isn't there something mechanical and formulaic about his
patterned signoff lines -- I mean compared to us normal humans
who repeatedly use the same exact sigs in message after message.
I think he/it's been dropping us a hint all along with the "tim_one"
address!!
Inquiring minds want to know! Lets play the Turing game with
Tim/Tim's-AI and see if we can guess!
Hey Tim: How many chickens does it take to cross the road?
Itai Katz
Thanks for explaining the bytecode situation to me; however, there is no
reason why some wrapper implemented in the assembly-code of the VM enable
Python programs to compile into bytecodes WITHOUT compromising its dynamic
typecasting?
BTW am I automatically now on the Python listserv? must I subscribe? if so,
where to?
Thanks,
Roi Katz
ik...@erols.com
Greg Stein
Again, even if you managed to write some code that compiled a Python
parse tree into Java VM bytecodes, you will likely run afoul of the Java
security system. It wants to see specific patterns in the bytecodes that
are very tuned towards Java source (as I recall, class instantiation was
an area where the JVM imposed some rigorous behaviors that are
incompatible with languages other than Java).
You might be able to get away with avoiding the security system a little
bit by saying that you have to run it as an app or sign the thing (note:
somebody just broke the Java signing mechanism in JDK 1.1). However, by
saying that you compile to the JVM, you'll give people a false sense of
being able to write Java applets using Python.
I'm not telling anybody to not try it :-) (go Jim!) but simply that
you'll need to be very much aware of that darn security stuff.
-g
Tim Peters
> [steve "lost highway" majewski inflames ...]
> ...
> What's changed in the last year has been my estimate of some
> of the secondary gains due to what I think is the reasonable (but
> arguable) belief that Java:
> (1) will largely replace C++ [& C] as an application programming
> language.
> (2) will provide a higher level of portability than is now common
> with C + standard posix libraries.
*If* I were an AI program, I would both dispute and embrace both sides of both
claims until we all got so lost in the maze of nested invocations that the
poor chicken couldn't even *see* the other side of the road. Short-circuiting
all that, to #1 I say we can hope; to #2, not if Microsoft can stop it <0.3
wink>.
> I don't think I'm overestimating you, Aaron.
It would be hard to overestimate Aaron! I've tried, & haven't succeeded yet.
> You're too opinionated to be NEVER wrong, but you've never
> been absurdly wrong before, which
Jeez, Steve, you just can't stop provoking tchrist, can you <wink>?
> is why I assumed there must be a communication problem.
Na, it's all e-mail artifacts. Trust me. If we were all in the same bar, we
would have punched each other out by now & reached harmonic convergence
despite that. The older I get, the more I hate everything ...
> BTW: I know Guido is never wrong, but that's a matter of
> theology -- like the way the Pope is never wrong.
Even worse than that -- I think the Pope has to be sitting in a magic chair
(or something) to be infallible. Guido just *is*.
> And I know I've been wrong, because Guido and Tim have told
> me so.
Wrong again, Steve: we've never said that. QED.
> But has anyone ever seen Tim be wrong ?
Nobody living, except Guido, and I wouldn't count on him living *much* longer
if he catches me in another misteake.
> ...You don't think that maybe during his absence from the list, he
> cobbled up an AI simulation of himself in his basement on a couple
> of KSR's he swiped when they stiffed him on his severance pay ? Hmmm.
> And, isn't there something mechanical and formulaic about his
> patterned signoff lines -- I mean compared to us normal humans
> who repeatedly use the same exact sigs in message after message.
> I think he/it's been dropping us a hint all along with the "tim_one"
> address!!
Ya, ya, ya, except ... if I were built out of KSR chips, I'd be running at 25
or 50 MHz, and would be wrong about ALMOST EVERYTHING almost ALL THE TIME just
due to being a computer! Think about it -- when's the last time you spent 20
hours straight debugging your son/wife/friend/neighbor/dog/ferret/snake? And
they *still* fell over anyway? Except in a direction you've never seen before
each time you try it? The easiest way to tell you're dealing with a computer
is when the other side keeps making the same moronic misteakes over and
misteakes over and misteakes over and misteakes over and misteakes over and
misteakes CTRL-C again.
> Hey Tim: How many chickens does it take to cross the road?
No number of Java chickens, because it isn't safe to cross the road.
but-it-only-takes-one-python-chicken-to-*build*-a-damn-road-ly y'rs - tim
Nick Leaton
Greg Stein wrote:
>
> Actually, Aaron's point about it probably not being possible is true,
> but for different reasons. The Java VM requires some really strict
> adherence to some security rules for how the bytecodes are used in a
> program. More specifically, because of those security rules, it is
> practically impossible for *anything* besides Java to compile to its VM
> and pass the security checks.
>
> It is a much wider problem that simply Python to the JVM. This affects
> any language that wants to target that VM.
>
What justification is there for this statement?
--
Nick
Andrew Robinson
Guido van Rossum <gu...@CNRI.Reston.VA.US> wrote:
>codes as follows:
>
> PVM JVM Pentium
> +------------------------------------------------------+--------+
>
>In other words, compiling Python to JVM isn't considerably easier than
>compiling Python to Pentium machine code.
>
Dumb question: Is anyone working on an Ansi-C-to-java-bytecode
compiler?
Sure, it would not necessarily be optimal. And in particular,
compiling python (or anything else) that way is going to take a hit of
an order of magnitude, because you'll be implemented OOP at the source
level rather than using whatever optimisations are built into the JVM.
But it would be a far more general tool than python-to-JVM. GCC
already suports many target architectures; why can't JVM be one more?
Then you can do not only Python in Java, but Perl and everything
else...
Andy Robinson
an...@hps1.demon.co.uk
Still programming for the day-job...
aaron watters
Just to get picky: "not really possible" != "impossible".
How many angels can dance on the head of a pin?
Also:
Steve:
>Java:
>(1) will largely replace C++ [& C] as an application programming language.
>(2) will provide a higher level of portability than is now common
> with C + standard posix libraries.
On (1), maybe. On (2) maybe, but as someone (I think from
Sun research about a year ago) once pointed out - why the
heck do (1) and (2) have to be tied up together? I have a feeling
that the fact that they *are* tied up together will not help anybody.
I'd actually go further than Guido, and say that it would be *easier*
to "compile" Python to 386 assembly than it would to JVM, because
JVM, for example, lacks function pointers. There have been lots
of portable machine languages, how'd we end up with this one?
(I know: the security thing, but I'd argue that's really an OS issue,
as I've argued before...).
And there are lots of ways to get lots of different kinds of
portability - I'd prefer a good cross-platform loosely-coupled flexible
well defined efficient distributed object approach - like ILU, or COM,
or, well, arguably Python itself...
I'd also disagree with Tim - Microsoft will not decide the fate of
java - the customers will (and the thousands of software firms
and MIS departments which supposedly should now toss all their
legacy code in the dumper). In this great "battle of the platforms"
some tend to forget that "pure java" is actually hostile to the majority of
existing software - including the mom-and-pop shops, not just
Microsoft or for that matter Python. This is why I find it hard to
imagine it will succeed outside of certain vertical markets (maybe
smart cash registers &c, who knows)... Java itself, of course, is
a good language, and I'd love to be able to use it easily in
combination with Python. -- Aaron Watters
=-=
Silicon Valley Sophism:
The belief that something will succeed "because it would
be cool." -- Jean Louis Gasset (?)
Guido van Rossum
> Dumb question: Is anyone working on an Ansi-C-to-java-bytecode
> compiler?
Sorry, no go. Java does not have pointers, only object references.
C's pointer semantics are impossible to implement with the JVM unless
you were to essentially reserve one Java array to simulate the
"memory" used by C.
Balaji Srinivasa
Guido van Rossum wrote:
>
> > Dumb question: Is anyone working on an Ansi-C-to-java-bytecode
> > compiler?
>
> Sorry, no go. Java does not have pointers, only object references.
> C's pointer semantics are impossible to implement with the JVM unless
> you were to essentially reserve one Java array to simulate the
> "memory" used by C.
they *had* to implement a C compiler. As the address of a variable is
pretty much irrelevant on a stack architecture, it was simulated by
using gigantic arrays (hence a crappy `C' compiler).
Balaji
--
-balaji at platinum.com
Johann Hibschman
In article <33673c20...@news.demon.co.uk>,
Andrew Robinson <an...@hps1.demon.co.uk> wrote:
>Dumb question: Is anyone working on an Ansi-C-to-java-bytecode
>compiler?
Dumber question: Why on earth would you want to?
I suppose this is a sign of my overall failure to understand the
Java phenomenon, but isn't ANSI C already a standard hardware-
independent language specification for which compilers already
exist for practially all architectures?
I can buy the argument that Java is a nice language, and the argument
that Java has a nice uniform set of libraries, but I've never
understood the appeal of this "JVM" business. It just seems like a
way to slow down code which could just as easily have been compiled
into something fast.
Am I missing the point entirely? I've never had any trouble getting
my ANSI C computational codes to compile on any machine I've tried.
Slightly puzzled,
- Johann
--
Johann A. Hibschman | Grad student in Physics, working in Astronomy.
joh...@physics.berkeley.edu | Probing pulsar pair production processes.
Dennis Lee Bieber
On 30 Apr 1997 18:54:44 GMT in comp.lang.python,
Johann Hibschman (joh...@physics20.berkeley.edu) declaimed:
>
> I suppose this is a sign of my overall failure to understand the
> Java phenomenon, but isn't ANSI C already a standard hardware-
> independent language specification for which compilers already
> exist for practially all architectures?
>
Ah, but the Java byte-code is a hardware independent
specification for BINARY executables...
>
> Am I missing the point entirely? I've never had any trouble getting
> my ANSI C computational codes to compile on any machine I've tried.
>
The idea is that the end user /won't have the source code!/...
All your work is still private to you, but your product can be used on
any machine with a JVM... Without them or you having to build it for
their machine...
Personally, I just see the return of the UCSD P-System -- which
was nearly as secure in a way <G> Only one output file open at a time
per floppy drive (because output files were created in the largest
contiguous free space, and /were/ contiguous, floppies had to be "packed"
every so often to consolidate free space).
--
> ============================================================ <
> wulf...@netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> Finger for PGP key | Bestiaria Support Staff <
> ============================================================ <
> Bestiaria Home Page: http://beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <
-=-=-=-=-=-
Usenet KILL-FILED for excessive off-topic SPAM:
worldnet.att.net cyberway.com.sg bconnex.net
Is your site going to be next?
Greg Stein
1) as Aaron was kind enough to point out: "practically impossible" !=
"impossible"
2) please always remember to ask nicely
3) empirical evidence. simply try it. you'll see.
As I mentioned in my other note, I believe one of the ugly parts was
instantiation. As I recall, you have to use Java class and instantation
semantics to pass the security checks. Java semantics are quite
different enough from other languages that it is "practically
impossible" to do a nice translation.
Guido also followed up with an excellent point regarding pointers. Note
that you could probably use some native-code extension to monkey with
pointer-related stuff, but then you're outside the JVM.
-g
--
Greg Stein (gst...@svpal.org) execfile("disclaimer.py")
Chris Hoffmann
>>>>> "Johann" == Johann Hibschman <joh...@physics20.berkeley.edu> writes:
Johann> In article <33673c20...@news.demon.co.uk>, Andrew
Johann> Robinson <an...@hps1.demon.co.uk> wrote:
>> Dumb question: Is anyone working on an Ansi-C-to-java-bytecode
>> compiler?
Johann> Dumber question: Why on earth would you want to?
<snip>
Johann> Am I missing the point entirely? I've never had any trouble
Johann> getting my ANSI C computational codes to compile on any
Johann> machine I've tried.
Yes, you've missed the point ;-)
The point is that YOU have to compile your code for EACH machine you
want your application to run on. If you didn't compile on some
platform, people on that platform are out of luck.
In principle, of course, you can make your ANSI C source code freely
available and let those other people compile it. But believe me (or
rather believe my company's porting department) that's not as easy as
you think.
In Java, however, you compile the file once and then anyone with a JVM
on their machine (i.e. just about everyone on the planet) is
guaranteed they can run it on their machine. [This is the theory at
least. I've heard that some of the standard libraries behave
differently on different platforms. I don't think this a JVM problem,
but is because either these libraries' official specifications aren't
precise enough or because the implementers were careless.]
Even more interesting, many languages can now compile to Java byte
codes, so you can actually write your program in Ada or ObjectRexx or
whatever and still know that anyone, anywhere can run it.
I've heard several people say that it is precisely the JVM that is the
most exciting thing about the Java phenomenon. The language is OK, web
applets don't really have a lot of practical applications, but finally
having a commonly accepted universal assembly language will have a
tremendous impact on computing.
Like I said, this is the the theory. Whether the JVM is a significant
performance hit, or whether vendors will insist on creating
platform-specific "enhanced" versions of the JVM, will determine how
things come out in reality.
Chris
--
Chris Hoffmann DataViews Corporation
chof...@dvcorp.com 47 Pleasant St. Northampton MA 01060
GCS d H s+: g+ ?p a w v+ C+$ US+ P++(++++) L E+(+++) N++ K W--->-- M+
V- po- Y+ t+ 5+(+++) Jx R G tv b+++ D+ B-() e+++ u++ h---- f r+++ n--- y++++
Samuel Tardieu
>>>>> "Greg" == Greg Stein <gst...@microsoft.com> writes:
Greg> The Java VM requires some really strict adherence to some
Greg> security rules for how the bytecodes are used in a program. More
Greg> specifically, because of those security rules, it is practically
Greg> impossible for *anything* besides Java to compile to its VM and
Greg> pass the security checks.
That's wrong: an Ada to JBC compiler exists (from Intermetrics,
http://www.inmet.com), and I heard of some other ports for Ada.
Ada and Java are semantically very close to each other, and the VM
instructions are very well suited for Ada needs (dispatching
vs. non-dispatching is determined at the time of the call
("invokevirtual" vs "invokenonvirtual"), ...).
Sam
--
Samuel Tardieu -- s...@ada.eu.org
Samuel Tardieu
>>>>> "Greg" == Greg Stein <gst...@svpal.org> writes:
Greg> Guido also followed up with an excellent point regarding
Greg> pointers. Note that you could probably use some native-code
Greg> extension to monkey with pointer-related stuff, but then you're
Greg> outside the JVM.
There is one more confusion here: it's perfectly possible to compile a
language which uses pointers into Java bytecode since Java treats any
object[1] as a pointer. The problem is not with pointer but with
pointers arithmetic: it will be very hard to translate C into Java
because operations on pointers can be made freely.
AppletMagic may be a proof of concept: Ada is a language with pointers
(but with limited and well-controlled pointers arithmetic) and is
compiled into Java bytecode.
Footnotes:
[1] "object" here designated a child of Java.lang.Object
Doug Wyatt
In article <199705011334.JAA03174@ithaca>, Chris Hoffmann
<chof...@dvcorp.com> wrote:
> I've heard several people say that it is precisely the JVM that is the
> most exciting thing about the Java phenomenon. The language is OK, web
> applets don't really have a lot of practical applications, but finally
> having a commonly accepted universal assembly language will have a
> tremendous impact on computing.
Yeah, this is what Byte magazine's feature on Java said too.
> Like I said, this is the the theory. Whether the JVM is a significant
> performance hit, or whether vendors will insist on creating
> platform-specific "enhanced" versions of the JVM, will determine how
> things come out in reality.
We're starting to see just-in-time compilers that convert the Java
bytecodes into native instructions.
Microsoft does indeed seem to want to get people attached to their superset
of Java.
Doug
---
Doug Wyatt music [,] software
do...@sonosphere.com http://www.sonosphere.com/sonosphere/
"Chaotic action is preferable to orderly inaction." - John Geirland
Michel de Groot
Doug Wyatt wrote:
>
> Microsoft does indeed seem to want to get people attached to their superset
> of Java.
>
> Doug
Most standard applications (word processors, spreadsheets) will work
just fine in Java. Performance degradation is not very much an issue on
fast machines, but the applications will work fine for years and years
or could be updated by replacing Java bytecode regularly. This is a
major threat to the Microsoft empirium.
Michel
> ---
> Doug Wyatt music [,] software
> do...@sonosphere.com http://www.sonosphere.com/sonosphere/
> "Chaotic action is preferable to orderly inaction." - John Geirland
--
Freddy's Law: Murphy was an optimist
Visit the Ducosim website at
www.euronet.nl/~ducosim
R.M. de Groot
Campuslaan 57-104
7522 NK Enschede
the Netherlands
tel. NL-053-4895100 (home)
NL-053-4894179 (work)
email: r.m.d...@student.utwente.nl (home)
gro...@cs.utwente.nl (work)