comp.lang.ada
 help / color / mirror / Atom feed
From: jsa@organon.com (Jon S Anthony)
Subject: Re: Java Risks  (Was: Ada News Brief - 96-05-24
Date: 1996/06/03
Date: 1996-06-03T00:00:00+00:00	[thread overview]
Message-ID: <JSA.96Jun3174808@organon.com> (raw)


In article <Pine.GSO.3.92.960602130408.12386B-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:


Richard,

I sent you an extended version of this in email, but here are a few
bits for public consumption...


> >  All languages add an RTE,
> > including (and in some sense, especially) Java.  What do you think the JVM
> > is???
> 
>   OK. Now, when I distribute an application in bytecode, what is it that
>   i am providing?  If I understand correctly, my bytecode is portable and
>   can be executed by any platform with a bytecode interpeter.  If the
>   standard for a bytecode interpreter is consistent from one platform
>   to another, my application is truly portable. No compilation required.

This is equally true for any single platform (OS/HW combination, JVM, etc.)


>   As new platforms, new processors, come on-line, all we need to do is
>   write a new Java bytecode interpreter to run the existing application.
>   Sounds good to me. I have no need to buy a license for your new version
>   the application that you have targeted to the new platform.

Yes, but then how do you get the JVM for the new platform?  As things
are currently going it looks like this will thrown in as a kind of
loss leader.  Just like Windoze/X is for Intel based machines.  Again
in this respect there really is no difference.  Now for completely new
HW, it is true that JVM has an upper hand because it is a lot simpler
to build a new JVM (as software thing) than a new piece of HW - of
course it prolly has a lot more bugs in it too! :-)


>   translated or emulated so they will run on new hardware. This is
>   usually not as efficient as running in native mode.  If one writes

First, emulation is just another word for interpreted.  Second, the
efficiency issue depends on several things.  For example, there are
cases where Alpha boxes running NT can "emulate" x486 Windoze code
about as fast and sometimes faster than the real thing.  Lastly,
J-code is in the same boat.  If "emulated" it will always be slower,
but if cast in silicon it will be just another HW architecture.


> > actually happened with P-code and there has even been some talk about
> > it with respect to J-code.
> 
>   Yes, I do recall P-Code.  Interesting point. Not sure if it applies to
>   this argument, though.

The only reason it does is that it gives a another indication that
"interpretation" has nothing to do with any of the issues you raise.
None.  Is the silicon P-code machine code somehow harder to decode
than the interpreted version?  Don't see how.


> > Again, this just plain makes no sense.
> > Now, you _can_ make an argument that the particular "interpreted"
> > code, viz. J-code, itself has some interesting aspects where it
> > maintains more "source" level type information than some other low
> > level architecture (oh, say, a SPARC).  But even then, what you're
> > claiming is a real stretch.
> 
>   So, can I write a bytecode interpreter for a brand X machine without
>   permission from the author of the Applet?

Can't make out what you're asking here: are you asking about a JVM for
a new HW? or a new interpreter for a Applet?  what applet?  If Sun
licenses the JVM architecture for peanuts or nothing, then sure you
can hack a new JVM for arbitrary new HW.

The main point of my quoted comment here is that you can make a claim
that the architecture evinced by J-code *is* higher level than your
standard RISC HW.  To *that* extent you *can* claim that J-code is
*easier* to work with when attempting a "decompile".  But it would
still be a pain.  Besides, which actual code are you going to attempt
to reconstruct?  The Ada? Java? Eiffel?  X?  What do you have anyway?
You're not going to find it much easier getting at algorithms here
than from straight machine code.


>   At the source code level, Ada is emminently portable. No argument.
>   So is Java.  Nor argument.  Java goes one step further and makes the
>   executable portable

But the JVM is *not* tied to Java the language.  If you really want an
example of apples to apple pickers just compare Ada (or Eiffel or Java
the language or ...) to the JVM (or J-code).


>   becuase it can be interpreted by bytecode.
>   Argument?    OK.  Now, which proprietary software product is more
>   secure, the executable created from Ada source code, or the
>   interpretable bytecode originating in Java?

The executable generated from Ada source that runs on the JVM?  The
standard SPARC executable from Java (I seem to recall that there *is*
a native Java compiler available from a house in England, but in any
event they are surely coming)?  Or how about the available just in
time native compilation of J-code to native code?


>   Jon, thanks for your ideas on this topic.  At some point, we will start
>   to bore the others on this forum, and we can take it private. Meanwhile,
>   I am still not certain that an interpreted language such as Java is as
>   low-risk as a compiled language such as Ada, or even Eiffel.

The key point is that Java *the language* is no more interpreted (via
byte code or what-have-you) than Ada or Eiffel.  And the JVM has only
a peripheral connection to Java the language.  Just as there turned
out to be compilers for P-code and the PVM for all sorts of languages,
there will be for J-code and the JVM.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com





             reply	other threads:[~1996-06-03  0:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-06-03  0:00 Jon S Anthony [this message]
  -- strict thread matches above, loose matches on Subject: below --
1996-05-24  0:00 Ada News Brief - 96-05-24.txt [1/1] AdaIC
1996-05-27  0:00 ` Tucker Taft
1996-05-28  0:00   ` Richard Riehle
1996-05-29  0:00     ` Andreas Zeller
1996-05-30  0:00       ` Java Risks (Was: Ada News Brief - 96-05-24 Richard Riehle
1996-05-31  0:00         ` Brian N. Miller
1996-06-02  0:00           ` Richard Riehle
1996-06-03  0:00           ` Ken Garlington
1996-06-04  0:00             ` Bill Brooks
1996-06-06  0:00               ` Bjarne Stroustrup <9758-26353> 0112760
1996-06-06  0:00                 ` Robert Dewar
     [not found]         ` <4omoh4$k0f@ansible.bbt.com <4ov36b$1665@watnews1.watson.ibm.com>
1996-06-04  0:00           ` Richard Riehle
1996-05-31  0:00 ` Jon S Anthony
1996-06-02  0:00   ` Richard Riehle
1996-06-01  0:00 ` Bob Crispen
1996-06-05  0:00   ` Alan Brain
1996-06-03  0:00 ` Norman H. Cohen
1996-06-03  0:00   ` Imonics Corporation
1996-06-07  0:00   ` Peter Wentworth
1996-06-05  0:00 ` Norman H. Cohen
1996-06-05  0:00   ` Bill Brennamw
1996-06-08  0:00   ` Brian N. Miller
1996-06-09  0:00 ` Jim Kingdon
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox