SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : MSFT Internet Explorer vs. NSCP Navigator

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: who wrote (57)6/16/1996 1:33:00 PM
From: Dontin Wang   of 24154
 
To answer your question about bytecode vs object-code:

As I understand it, the Java Virtual Machine (JVM) is a specification for
an abstract computing machine at the binary level. As such,
machine instructions, data types and lengths, and byte-ordering are all
specified independently of any particular hardware or platform.

Java bytecode is the result of processing Java code through a Java
compiler, and conforms to the JVM specifications. As such, it can be
executed on any JVM (but someone needs to supply a JVM for each
platform that supports Java--SUNW built the Mac JVM, MSFT is
working on the Windows JVM, for example).

The power of this scheme is what has everyone excited--code that can
run on all sorts of different platforms without change or recompilation--
because it goes against an abstract specification that everyone agrees
to (licensed). The downside, of course, is that someone must
implement the JVM for each new platform to be supported (Mac users
had to wait a long time, for example, and I'm still not sure about JVM
for Mips or Alpha). Another downside is generalized code that doesn't
take advantage of the strength or uniqueness of the running platform.

With C++, you have the traditional "source code -> compiler -> machine
specific binary" cycle. In this case, you are generating binary code
that is targeted for a specific type of CPU, so it will be useless on a
different type of CPU.

The advantage is more efficient/optimized code (generally), but the
downside is that you have more complex code or procedures when
trying to support multiple platforms.

To solve this problem, you either recompile for the other CPU, or you
write a CPU-emulator which makes the other CPU look and act like the
first type of CPU (Insignia has a Intel emulator for many Unix
platforms, DEC has an Intel emulator for Alpha, for example).

As far as Java--the language--is concerned:
Java as a language is really not much different than standard C++,
but it does have native support for threads, and eliminates some
features that comprise security or "promote" dangerous coding
practices (ie scalar variables and memory pointers). It is a small,
compact language more in the tradition of C, actually, and relies
heavily on function libraries. As such, it appeals both to purists who
like it's compact/simple design, to new programmers
(because small==easier to learn, in this case) and to bit-heads who
like the flexibility to use or make a new library of functions on a whim.

Go Bulls!!

DISCLOSURE: I am a Microsoft employee, but my comments only represent my
own thoughts and opinions and in no way reflect a position, endorsement,
or recommendation by Microsoft, it's officers, representatives, or
associates.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext