* Ada News Brief - 96-05-24.txt [1/1]
@ 1996-05-24 0:00 AdaIC
1996-05-27 0:00 ` Tucker Taft
` (6 more replies)
0 siblings, 7 replies; 37+ messages in thread
From: AdaIC @ 1996-05-24 0:00 UTC (permalink / raw)
Ada News Brief
Week Ending: May 24, 1996
*********************************************
AJPO CHIEF CHARLES ENGLE PROFILED IN FCW
*********************************************
Federal Computer Week recently featured a profile on Charles
Engle, Jr., Ada Joint Program Office (AJPO) Chief and leader
of the Year 2000 team at Defense Information Systems Agency.
As head of the AJPO, Engle's task is to educate people about
DoD's Ada policy and to foster the development of Ada
technology through cooperative work with DoD organizations,
vendors and the university community.
The article discusses not only Engle's current role in the
Ada community but his past involvement with Ada beginning
with his role in developing Ada 83 as a graduate student at
Stanford University. Engle stresses the importance of the
DoD's Ada policy and notes that however attractive people
may find C++, its lack of standardization and technical
limitations often make it a poor substitute for Ada.
SOURCE:
Monroe, John Stein. "Ada point man staves off chaos,"
Federal Computer Week. May 6, 1996: 58,60.
**************************************************************
PROSPECTS LOOK GOOD FOR INCORPORATING Ada 95 WITH JAVA
VIRTUAL MACHINE
**************************************************************
Peter Coffee discusses the concept of the Java Virtual
Machine becoming a target for languages other than Java in
his article, "Java Virtual Machine Brews a Revolution."
Coffee notes that Ada 95, with both object-orientation and
multiple threads, is a clear candidate for this strategy and
discusses the open beta test that is being conducted by
Intermetrics. The company is testing a technology for
mapping Ada 95 to the JVM instruction set. For further
information, check http://www.inmet.com/javadir/download/.
SOURCE:
Coffee, Peter. "Java Virtual Machine Brews a Revolution,"
PC Week. May 6, 1996: 18.
*****************************
JAVA TO TAKE OVER FOR Ada?
*****************************
Defending Sun Microsystems' claims that Java is smoother and
more efficient than Ada and that Ada will be supplanted by
Java, Tucker Taft, chief scientist of Intermetrics, Inc.,
stated, "Of course they would love to see Java as the next
Ada in DoD. It's a lot of hype. Ada has everything Java has,
and the binary code is so similar that we are able to hijack
all its strengths without losing anything." Further
defending Ada's position in the DoD is Chuck Engle, chief of
the Ada Joint Program Office, "It's not true that Java will
phase out Ada," he said. "Java is Ada 95 schematics with C++
syntax. Ada is safer. It is easier to read and understand."
SOURCE:
Finnegan, Lisa. "Ada loyalists go head-to-head with Java
promoters," Government Computer News. May 13, 1996: 38-
39.
**************************************************
DISCOVER Ada 95's STRING HANDLING CAPABILITIES
**************************************************
Richard Riehle's Ada column in the May issue of Journal of
Object-Oriented Programming discusses "one of the seldom
explored issues of the new Ada standard: strings." Riehle
discusses an Ada developers need for a consistent, portable,
complete definition for string-handling routines that would
eliminate the need for recoding simple string algorithms
over and over.
Riehle states that Ada 95 has remedied this issue by
defining a set of packages for both character handling and
string handling. It even includes packages for wide
characters and wide strings. Riehle continues by offering
examples and explanations for Ada 95 string capabilities.
SOURCE:
Riehle, Richard. "Stringing along with Ada 95, "Journal of
Object-Oriented Programming." May 1996: 49-54.
************************************
THOMSON RELEASES OBJECTAda 6.2.1
************************************
Thomson Software Products recently announced the
availability of ObjectAda 6.2.1 on Sun Microsystems' Ultra
SPARC high-speed 64-bit architecture. ObjectAda 6.2.1
provides users with the new object-oriented features of Ada
95, coupled with the power of a new high-performance
hardware platform. ObjectAda 6.2.1 offers many advanced
features to accelerate the development process, including an
optimized, object-oriented Ada compiler, software component
libraries, and a syntactic and semantic editor to reduce the
edit-compile cycle. In addition, an Ada 83-to-Ada 95
compilation switch facilitates the transition to the newly
refined Ada language.
For more information on ObjectAda 6.2.1, contact Andrea
Williams, 619/457-2700, awilliams@thomsoft.com
SOURCE:
Thomson Software Products press release from Business Wire
via Individual Inc.
************************************************
MOCK BALLOT OPEN FOR Ada BINDING TO P1003.1g
************************************************
The P1003.5c working group of the Portable Applications
Standards Committee(PASC) of the IEEE Computer Society is
conducting a mock ballot of the draft IEEE POSIX standard
for an Ada binding to P1003.1g, "Protocol Independent
Interfaces" (i.e., sockets and XTI network interfaces).
If you would like to participate in the mock ballot, or take
an active role in the working group, or if you simply have
an interest in observing the flow of information exchanged
on this subject, please subscribe to this list by sending
mail to: posix-ada-net-request@pasc.org with the word
"subscribe" in the body of the message.
SOURCE:
Shane P. McCarron, Testing Research Manger, P1003.5c Working
Group, ahby@themacs.com
*******************************************
TARTAN ACQUIRED BY TEXAS INSTRUMENTS
*******************************************
Tartan, Inc., a leading provider of Ada compilers, has
recently been acquired by Texas Instruments. Tartan is a
leading third-party provider of highly optimizing software
tools for developers of real-time, embedded digital signal
processing (DSP) applications.
The combined expertise of both companies should result in
producing the industry's highest performance DSP software
tools. "Tartan is the clear technical leader in Ada and C++
compilers within the DSP industry, and this acquisition
doubles our DSP development support resources. TI will be
able to take advantage of Tartan's expertise and technology
to dramatically accelerate TMS320 DSP technology development
and to provide the best DSP customer application support in
the industry," said Mike Hames, TI Semiconductor Group vice
president and worldwide DSP manager.
SOURCE:
Texas Instruments press release, May 6, 1996.
*****************
Ada 95 WORKSHOP
*****************
A workshop titled "Software Methods and Tools for Ada 95" is
being organized for September 16-20, 1996 in Brest, France.
For more information, contact:
Yvon Kermarrec
Telecom Bretagne
BP 832
29285 Brest, France
e-mail : yvon.kermarrec@enst-bretagne.fr
http://www-info.enst-bretagne.fr/~kermarre/
Ada95Workshop.html
SOURCE:
Dr. Yvon Kermarrec
***********************************************************
The AdaIC's "Ada News Brief" is a compilation of summaries from Ada-
related articles in trade magazines, newsletters and press releases. The
AdaIC welcomes suggestions for and pointers to Ada-related articles.
Contact the AdaIC at:
Ada Information Clearinghouse
P.O. Box 1866
Falls-Church, VA 22041
1-800/232-4211 or 703/681-2466
adainfo@sw-eng.falls-church.va.us
http://sw-eng.falls-church.va.us
To subscribe to the Ada News Brief listserv, send a message to:
listproc@sw-eng.falls-church.va.us
In the body of the message, write:
subscribe adanews (your name)
To unsubscribe, write:
unsubscribe adanews
No signatures please.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
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-27 0:00 ` Ada News Brief - 96-05-24.txt [1/1] Brian Rogoff
` (5 subsequent siblings)
6 siblings, 1 reply; 37+ messages in thread
From: Tucker Taft @ 1996-05-27 0:00 UTC (permalink / raw)
AdaIC (adainfo@sw-eng.falls-church.va.us) wrote:
: Ada News Brief
: Week Ending: May 24, 1996
: ... Tucker Taft, chief scientist of Intermetrics, Inc.,
: stated, "Of course they would love to see Java as the next
: Ada in DoD. It's a lot of hype.
^^^^^^^^^^^^^^^^^^^ This is either a misquote,
or taken out of context. I am a fan of Java, and I don't think it
is just a lot of hype.
Be that as it may, I do believe Ada has a number of
advantages, particularly with respect to the thoroughness
of the compile-time checking provided by Ada (e.g. strong type
distinctions between numeric types, enumeration types, array types,
etc.). For example, Java treats all "int"s as freely interconvertible,
and has no separate concept of an enumeration type. This means that a
Java interface communicates less information than an Ada interface, both
to the reader, and to the compiler.
The great thing about the Ada/Java combination is that we get the
best of both worlds, getting the robust consistency checking, generic
templates, enumeration types, etc., from the Ada side, while also
getting garbage collection, dynamic linking, Web-browser integration, etc.
from the Java side.
-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/
Intermetrics, Inc. Cambridge, MA USA
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-05-27 0:00 ` Tucker Taft
@ 1996-05-28 0:00 ` Richard Riehle
1996-05-29 0:00 ` Andreas Zeller
0 siblings, 1 reply; 37+ messages in thread
From: Richard Riehle @ 1996-05-28 0:00 UTC (permalink / raw)
To: Tucker Taft
On 27 May 1996, Tucker Taft wrote:
> AdaIC (adainfo@sw-eng.falls-church.va.us) wrote:
> : Ada News Brief
> : Week Ending: May 24, 1996
>
> : ... Tucker Taft, chief scientist of Intermetrics, Inc.,
> : stated, "Of course they would love to see Java as the next
> : Ada in DoD. It's a lot of hype.
> ^^^^^^^^^^^^^^^^^^^ This is either a misquote,
> or taken out of context. I am a fan of Java, and I don't think it
> is just a lot of hype.
Thanks for making this correction, Tucker. It was a little surprising
to think you might view Java as a lot of hype. In some respects, it
probably is. However, it does demonstrate some very nice capabilities
for representing ideas in software.
> Be that as it may, I do believe Ada has a number of
> advantages,
[snip, snip, snip]
Along with the comparisons you cite, there is also the problem with
Java's proletarianization of the software product. This will lead to a
question of just what it is that software developers actually sell. If
we are selling the bloom of our gray matter in the form of a complex
array of binary digits, we have some interest in protecting that bloom
from others for our personal economic benefit.
Java's democratic nature is a blessing for open exhange of ideas. It
would not lend itself easily to the protection of ideas. When we want
to minimize the risk of sacrificing our intellectual property through
too easy public access, nothing does the job as well as Ada.
There is still some virtue in keeping some ideas secret. Ada does that
better than Java.
Richard Riehle
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-05-28 0:00 ` Richard Riehle
@ 1996-05-29 0:00 ` Andreas Zeller
1996-05-30 0:00 ` Robert Dewar
1996-05-30 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 Richard Riehle
0 siblings, 2 replies; 37+ messages in thread
From: Andreas Zeller @ 1996-05-29 0:00 UTC (permalink / raw)
Richard Riehle (rriehle@nunic.nu.edu) wrote:
> Java's democratic nature is a blessing for open exhange of ideas. It
> would not lend itself easily to the protection of ideas. When we want
> to minimize the risk of sacrificing our intellectual property through
> too easy public access, nothing does the job as well as Ada.
I don't get the point in here. If I have some compiled code, where's
the difference in whether the source code was written in Java or Ada?
If I have some bytecode for the Java virtual machine, couldn't it have
been produced by some Ada compiler as well?
Although there are many Java interpreters and Ada compilers, neither
the Java language nor the Ada language impose a particular model of
program execution (compiler, interpreter, distribution, etc.)
Saying that one language has a greater risk in disclosing intellectual
property is just as misleading than saying that one language is more
efficient than another. These are properties of the programming and
execution environment, not of the language itself. I don't see why
choosing Ada or Java should make a difference here.
--
Andreas Zeller (zeller@acm.org)
Technische Universitaet Braunschweig, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-05-29 0:00 ` Andreas Zeller
@ 1996-05-30 0:00 ` Robert Dewar
1996-06-01 0:00 ` AdaWorks
1996-06-01 0:00 ` AdaWorks
1996-05-30 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 Richard Riehle
1 sibling, 2 replies; 37+ messages in thread
From: Robert Dewar @ 1996-05-30 0:00 UTC (permalink / raw)
Richard Riehle (rriehle@nunic.nu.edu) wrote:
> Java's democratic nature is a blessing for open exhange of ideas. It
> would not lend itself easily to the protection of ideas. When we want
> to minimize the risk of sacrificing our intellectual property through
> too easy public access, nothing does the job as well as Ada.
That's a very strange viewpoint. Of course we are not talking languages
here, as someone has pointed out, but rather typical environments.
In many ways you can see Java *precisely* as a means of protecting
intellectual property and aiding software hoarding. Suppose you want
to distribute a program that will run on all systems. In the past,
the easiest, indeed the only really practical way, to do this was
to distribute sources. Now with the universal availability of Java
byte code interpretors, you can distribute JBC, and avoid distributing
the source.
THe discussion about free vs proprietary software is of course one that
continues, and is not strictly relevant to this discussion, but claiming
that Java is a blow in the direction of freedom is truly ironic!
All in all, the quote from Richard is quite bizarre. Even with a friendly
interpretation, I can't make any sense out of it at all. Ada is a completely
open language. It has an international standard and NO ONE can lay claim to
any intellectual property rights in Ada itself. You can of course write
proprietary programs in Ada, but that is true of any language.
Richard, can you try to explain what on earth you mean here!
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-05-30 0:00 ` Robert Dewar
@ 1996-06-01 0:00 ` AdaWorks
1996-06-01 0:00 ` Robert Dewar
1996-06-01 0:00 ` AdaWorks
1 sibling, 1 reply; 37+ messages in thread
From: AdaWorks @ 1996-06-01 0:00 UTC (permalink / raw)
Robert Dewar (dewar@cs.nyu.edu) wrote:
: Richard Riehle (rriehle@nunic.nu.edu) wrote:
: > Java's democratic nature is a blessing for open exhange of ideas. It
: > would not lend itself easily to the protection of ideas. When we want
: > to minimize the risk of sacrificing our intellectual property through
: > too easy public access, nothing does the job as well as Ada.
: That's a very strange viewpoint. Of course we are not talking languages
: here, as someone has pointed out, but rather typical environments.
: In many ways you can see Java *precisely* as a means of protecting
: intellectual property and aiding software hoarding. Suppose you want
: to distribute a program that will run on all systems. In the past,
: the easiest, indeed the only really practical way, to do this was
: to distribute sources. Now with the universal availability of Java
: byte code interpretors, you can distribute JBC, and avoid distributing
: the source.
Robert,
I re-read the above paragraph, and appreciate the logic of your statement.
Perhaps the JBC is sufficient protection for those who are ordinary users.
My concern is for those who specialize in purloining industrial secrets.
Will JBC be secure enough to prevent someone from using it to reverse
engineer my software product?
Richard Riehle
--
richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX 328-1112
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-06-01 0:00 ` AdaWorks
@ 1996-06-01 0:00 ` Robert Dewar
0 siblings, 0 replies; 37+ messages in thread
From: Robert Dewar @ 1996-06-01 0:00 UTC (permalink / raw)
Richard asks
" Will JBC be secure enough to prevent someone from using it to reverse
engineer my software product?"
The answer is definitely NO!
But it is also the case that machine language is easy enough to reengineer
or reverse engineer if you want to. If you want to take a commercial
program for the PC, and spend the time, there are powerful disassembly
and analysis tools available that will enable you to do this reverse
engineering, no matter HOW much attempt has been made to obfuscate (in
extreme cases, you will need logic analyzers and in-circuit emulators,
but this is all very accessible and very practical technology).
Almost anyone working at a low level on PC's has had to spend time
reverse engineering parts of DOS for instance to understand what was
going on, and as an example, take a look at the (perfectly atrocious)
ruling against Stacker in the Microsoft-Stacker case (I am talking
about the counter award, not the main award in the other direction).
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-05-30 0:00 ` Robert Dewar
1996-06-01 0:00 ` AdaWorks
@ 1996-06-01 0:00 ` AdaWorks
1996-06-01 0:00 ` Robert Dewar
1 sibling, 1 reply; 37+ messages in thread
From: AdaWorks @ 1996-06-01 0:00 UTC (permalink / raw)
Robert Dewar (dewar@cs.nyu.edu) wrote:
: Richard Riehle (rriehle@nunic.nu.edu) wrote:
: > Java's democratic nature is a blessing for open exhange of ideas. It
: > would not lend itself easily to the protection of ideas. When we want
: > to minimize the risk of sacrificing our intellectual property through
: > too easy public access, nothing does the job as well as Ada.
: That's a very strange viewpoint. Of course we are not talking languages
: here, as someone has pointed out, but rather typical environments.
[snip, snip, snip ]
: byte code interpretors, you can distribute JBC, and avoid distributing
: the source.
Perhaps my observation can be summed up in terms of the ease of
reverse engineering. It seems to me easier to reverse engineer
"bytecode" than pure executable code. Perhaps not. But this is
criticism I have seem raised in the computing press, including
Software Magazine.
: THe discussion about free vs proprietary software is of course one that
: continues, and is not strictly relevant to this discussion, but claiming
: that Java is a blow in the direction of freedom is truly ironic!
I am not complaining about free versus proprietary software. I applaud
the availability of free software, especially products such as GNAT.
However, I do have concerns for those commercial products in which there
is a substantial investment and which need to be protected as licensed,
rather than "free." The security associated with Java is a legitmate
question.
: All in all, the quote from Richard is quite bizarre. Even with a friendly
: interpretation, I can't make any sense out of it at all.
Robert, I appreciate your effort at a friendly interpretation. And that
is not intended as sarcasm.
: Ada is a completely
: open language. It has an international standard and NO ONE can lay claim to
: any intellectual property rights in Ada itself. You can of course write
: proprietary programs in Ada, but that is true of any language.
The issue is not the propietary nature of the language. It is, rather,
the security of the final product deployed in that language. I am not
alone in my suspicion that Java and its associated bytecode may be
vulnerable to a variety of compromises. A software product, created
in Ada, would probably be less at jeopardy after deployment.
I am not denigrating the virtues of Java. It will have, already has,
an important place in the development of open applications. I am
suggesting that it is the very openess of those applications which
may put them at greater risk.
It would be a great comfort if I could be sure I was completely
wrong about this.
As to the openess of Ada. That is a different issue. The language
source code is pretty consistently portable. The executables rarely
are. The complexity of a deployed Ada program would present a formidable
challenge to anyone who wanted to reverse-engineer it. What is a virtue
for Ada, is not a virtue for Java.
Richard Riehle
--
richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX 328-1112
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-06-01 0:00 ` AdaWorks
@ 1996-06-01 0:00 ` Robert Dewar
1996-06-01 0:00 ` Mike Young
1996-06-04 0:00 ` Richard Riehle
0 siblings, 2 replies; 37+ messages in thread
From: Robert Dewar @ 1996-06-01 0:00 UTC (permalink / raw)
I find the claim that JBC is easier to reverse engineer than machine
code unsupportable from a technical point of view. JBC is just machine
code for a virtual machine. It is true this is a higher level machine
code, which makes a difference, but that difference can be in either
direction. Sometimes the encoding of stuff at a high level can be
harder to disentangle. For example, access types in an Ada source
program get translated to Java classes. Is it really true that this
makes algorithms that at a conceptual level use pointers easier to
understand by reverse engineering -- I think not.
At least it is now clear what Richard is concerned with (the mention of
reverse engineering was not in his original note), but it is also pretty
clear that this his opinion is borrowed from others rather than based on
technical analysis, and I suspect that the opinion, as stated in the trade
press, may also be based on a general theory that interpretors are easier
to reverse engineer.
I am unconvinced, though to be fair, you really would have to try doing
some reverse engineering to be sure. I think what you would find out is
that some programs are far easier than others to reverse engineer, and
these fundamental differences (having to do with how involved the
algorithms are, and how extensively the code is optimized, etc.) will
be much more significant than any minor difference caused by different
machine models.
Finally, it is important to emphasize that this has *nothing at all* to
do with the Java language, but rather with the specific delivery methods,
i.e Richard's comments about reverse engineering apply to Ada or any
other language converted to JBC, and do not apply to Java programs that
are compiled into hard machine code.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-06-01 0:00 ` Robert Dewar
@ 1996-06-01 0:00 ` Mike Young
1996-06-03 0:00 ` Robert Dewar
1996-06-04 0:00 ` Richard Riehle
1 sibling, 1 reply; 37+ messages in thread
From: Mike Young @ 1996-06-01 0:00 UTC (permalink / raw)
JBC is *very* easily decompiled. All class member names are directly
accessible in the class file, as are all classes and symbols referenced
from that class. These names are exposed to support Java's run-time
binding; a moment's reflection makes it very clear that this cannnot be
otherwise. You don't have to take my word on this; the details are in
the Java Virtual Machine spec, particularly section 2, the class file
format. It was less than a week's effort to extract use, dependency, and
structure graphs from Java class files. The only information not
directly available are local variable names.
Mike.
=============
Robert Dewar wrote:
>
> I find the claim that JBC is easier to reverse engineer than machine
> code unsupportable from a technical point of view. JBC is just machine
> code for a virtual machine. It is true this is a higher level machine
> code, which makes a difference, but that difference can be in either
> direction. Sometimes the encoding of stuff at a high level can be
> harder to disentangle. For example, access types in an Ada source
> program get translated to Java classes. Is it really true that this
> makes algorithms that at a conceptual level use pointers easier to
> understand by reverse engineering -- I think not.
>
> At least it is now clear what Richard is concerned with (the mention of
> reverse engineering was not in his original note), but it is also pretty
> clear that this his opinion is borrowed from others rather than based on
> technical analysis, and I suspect that the opinion, as stated in the trade
> press, may also be based on a general theory that interpretors are easier
> to reverse engineer.
>
> I am unconvinced, though to be fair, you really would have to try doing
> some reverse engineering to be sure. I think what you would find out is
> that some programs are far easier than others to reverse engineer, and
> these fundamental differences (having to do with how involved the
> algorithms are, and how extensively the code is optimized, etc.) will
> be much more significant than any minor difference caused by different
> machine models.
>
> Finally, it is important to emphasize that this has *nothing at all* to
> do with the Java language, but rather with the specific delivery methods,
> i.e Richard's comments about reverse engineering apply to Ada or any
> other language converted to JBC, and do not apply to Java programs that
> are compiled into hard machine code.
--
-----------------------------------------------------------------
Michael Young, Technologist Phone: (312)587-2329 Ext 3041
Strategic Technology Resources Fax: (312)266-9161
Chicago, IL 60610 mailto:mikey@str.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-06-01 0:00 ` Mike Young
@ 1996-06-03 0:00 ` Robert Dewar
0 siblings, 0 replies; 37+ messages in thread
From: Robert Dewar @ 1996-06-03 0:00 UTC (permalink / raw)
Mike says
"JBC is *very* easily decompiled. All class member names are directly
accessible in the class file, as are all classes and symbols referenced
from that class. These names are exposed to support Java's run-time
binding; a moment's reflection makes it very clear that this cannnot be
otherwise. You don't have to take my word on this; the details are in
the Java Virtual Machine spec, particularly section 2, the class file
format. It was less than a week's effort to extract use, dependency, and
structure graphs from Java class files. The only information not
directly available are local variable names.
"
Unconvincing. Of course the names of standard classes are exposed, this
is no different from seeing the name SQRT in a Fortran program (where
SQRT is in a dynamic link library). But you can shroud the names of your
own classes if you are interested in obfuscation, just as you would
shroud variable names in other circumstances.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-06-01 0:00 ` Robert Dewar
1996-06-01 0:00 ` Mike Young
@ 1996-06-04 0:00 ` Richard Riehle
1 sibling, 0 replies; 37+ messages in thread
From: Richard Riehle @ 1996-06-04 0:00 UTC (permalink / raw)
To: Robert Dewar
Robert,
Thank you for you commentary on my original post. I certainly did not
make myself clear first time around. However, it is nice to know that,
although your remain unconvinced, you do recognize the rationale for
the underlying concerns.
Richard Riehle
^ permalink raw reply [flat|nested] 37+ messages in thread
* Java Risks (Was: Ada News Brief - 96-05-24
1996-05-29 0:00 ` Andreas Zeller
1996-05-30 0:00 ` Robert Dewar
@ 1996-05-30 0:00 ` Richard Riehle
1996-05-31 0:00 ` Brian N. Miller
` (2 more replies)
1 sibling, 3 replies; 37+ messages in thread
From: Richard Riehle @ 1996-05-30 0:00 UTC (permalink / raw)
To: Andreas Zeller
Andreas,
Thanks for you commentary on my observations regarding the potential risks
associated with Java for proprietary software products.
On 29 May 1996, Andreas Zeller wrote:
> I don't get the point in here. If I have some compiled code, where's
> the difference in whether the source code was written in Java or Ada?
> If I have some bytecode for the Java virtual machine, couldn't it have
> been produced by some Ada compiler as well?
The Java code could certainly be produced by an Ada compiler or
an Eiffel compiler, etc. No argument with that. In fact, Intermetrics
has a product which does this, and ISE is working on an Eiffel compiler
that will do this.
> Although there are many Java interpreters and Ada compilers, neither
> the Java language nor the Ada language impose a particular model of
> program execution (compiler, interpreter, distribution, etc.)
I think you may have identified a key difference in the opening
lines of the preceding paragraph. Compiled source code is usually
optimized, and passed through other processes (linkers, binders, etc.)
which makes applications a bit more difficult to unravel back to their
original source code. Ada adds an additional layer in the form of an
RTE which varies from one compiler publisher to another.
Interpreted code is relatively easy to reverse-engineer. Consequently,
it is harder to protect proprietary algorithms.
> Saying that one language has a greater risk in disclosing intellectual
> property is just as misleading than saying that one language is more
> efficient than another. These are properties of the programming and
> execution environment, not of the language itself. I don't see why
> choosing Ada or Java should make a difference here.
One of Java's premier virtues is is portability. Another is its ease
of use. Neither of those features should be weakened. However, both
features make it easier to reverse-engineer applications written in
Java. Let me emphasize that I do not see this as a bad thing.
On the other hand, for publishers of commercial software products, there
is greater security of the intellectual property for compiled code than
for interpreted code.
In many ways, Java is BASIC for the next century. In time, Java will be
offerred as a compiled language, clever people will add new features to
make it more secure, and others will tack on features to make it more
incomprehensible. Already, feature-creep is beginnning to manifest
itself as self-enlightened software gurus conclude that Java would be
even better if it just had this one or two more features.
I like Java. I hope it can survive long enough in its present form long
enough to resist the wide-spread temptation to "make it better." Let it
mature. Let its users mature. Then, later (much later) revisit the
language design. One of the problems with C++ is that it is evolving
beyond Stroustop's original vision into a collection of features in
which seem to be on a collsion course with each other. Somehow, the
ISO Ada 95 standard managed to improve on the ISO Ada 87 standard
without mangling the language.
Anyway, my main point is that Java's very benefits for interactive
software are also its drawbacks for secure software. It is a simple
trade-off. But it needs to be recognized.
Richard Riehle
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
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-05-31 0:00 ` Java Risks (should be Java mis-speak) The Right Reverend Colin James III
[not found] ` <4omoh4$k0f@ansible.bbt.com <4ov36b$1665@watnews1.watson.ibm.com>
2 siblings, 2 replies; 37+ messages in thread
From: Brian N. Miller @ 1996-05-31 0:00 UTC (permalink / raw)
In article <Pine.GSO.3.92.960530095503.21075A-100000@nunic.nu.edu>, Richard Riehle <rriehle@nunic.nu.edu> writes:
|
| Java is BASIC for the next century.
Now that's .sig worthy!
| One of the problems with C++ is that it is evolving
| beyond Stroustop's original vision into a collection of features in
| which seem to be on a collsion course with each other.
A disbelieve that C++ is evolving awkwardly. Is there a publication
which claims so? Or is this 2-bit usenet opinion? ;')
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-05-31 0:00 ` Brian N. Miller
@ 1996-06-02 0:00 ` Richard Riehle
1996-06-03 0:00 ` Ken Garlington
1 sibling, 0 replies; 37+ messages in thread
From: Richard Riehle @ 1996-06-02 0:00 UTC (permalink / raw)
To: bnm
On 31 May 1996, Brian N. Miller wrote:
> In article <Pine.GSO.3.92.960530095503.21075A-100000@nunic.nu.edu>, Richard Riehle <rriehle@nunic.nu.edu> writes:
> |
> | Java is BASIC for the next century.
>
> Now that's .sig worthy!
Thanks. I actually think Java is a worthwhile contribution in
the evolution of software tool-building.
> A disbelieve that C++ is evolving awkwardly. Is there a publication
> which claims so? Or is this 2-bit usenet opinion? ;')
It is probably a two-bit Usenet opinion.
There are aspects of C++ that, as orginally conceived by Dr.
Stroustrup, make very good sense. The fundamental idea of
expanding the stuct into a class was a stroke of brilliance.
Now, C++ is becoming a larger language than Ada. And the behavior
of some of the new features seems to be making the possible
interactions between those features more complex, and even more
unpredictable. In particular, the exception mechanism in C++
is fraught with potential dangers. There are other points one
could make in this regard, but it would take to many pages to
enumerated them all.
It does amuse me, however, to read comments in periodicals that
assume that C++ is less complex than Ada because "Ada was designed
by a committee." Of course, Ada was not designed by a committee,
but no matter. C++,as it goes through the ISO standardization
process, also undergoes a transformation based on input from the
international software community. In the end, ISO C++ may end up
as more the product of a committee than Ada.
Richard Riehle
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
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
1 sibling, 1 reply; 37+ messages in thread
From: Ken Garlington @ 1996-06-03 0:00 UTC (permalink / raw)
Brian N. Miller wrote:
>
>
> A disbelieve that C++ is evolving awkwardly. Is there a publication
> which claims so? Or is this 2-bit usenet opinion? ;')
See Plauger's comments in Embedded Systems Programming, for example.
(I'm not sure why an opinion in a publication is necessarily better
than one on the Internet, but nonetheless, there it is...)
--
LMTAS - "Our Brand Means Quality"
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-06-03 0:00 ` Ken Garlington
@ 1996-06-04 0:00 ` Bill Brooks
1996-06-06 0:00 ` Bjarne Stroustrup <9758-26353> 0112760
0 siblings, 1 reply; 37+ messages in thread
From: Bill Brooks @ 1996-06-04 0:00 UTC (permalink / raw)
In article <31B2B06A.43FE@lmtas.lmco.com>,
Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:
>Brian N. Miller wrote:
>>
>>
>> A disbelieve that C++ is evolving awkwardly. Is there a publication
>> which claims so? Or is this 2-bit usenet opinion? ;')
>
>See Plauger's comments in Embedded Systems Programming, for example.
>(I'm not sure why an opinion in a publication is necessarily better
>than one on the Internet, but nonetheless, there it is...)
>
I too tend to disbelieve claims that C++ is evolving awkwardly, but
anyone who hasn't seen the <em> reams</em> of material published on
this topic must be living under a rock! The number of articles on the
error-proness of C++ exception handling alone could supply all the
material for a graduate level seminar.
Start out with: <quote>The Evolution of C++: Language Design in the
Marketplace of Ideas</quote>, 1993, edited by Jim Waldo, which traces
the history of C++ from USENIX conferences to today's most popular
OOPL. Waldo concludes that the language at one point had a clear
design center, but that it doesn't now.
--
"More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other reason -- including blind
stupidity." -- Wm. A. Wulf
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-06-04 0:00 ` Bill Brooks
@ 1996-06-06 0:00 ` Bjarne Stroustrup <9758-26353> 0112760
1996-06-06 0:00 ` Robert Dewar
0 siblings, 1 reply; 37+ messages in thread
From: Bjarne Stroustrup <9758-26353> 0112760 @ 1996-06-06 0:00 UTC (permalink / raw)
wbrooks@lwaxana.acs.calpoly.edu (Bill Brooks) writes
> In article <31B2B06A.43FE@lmtas.lmco.com>,
> Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:
> >Brian N. Miller wrote:
> >>
> >>
> >> A disbelieve that C++ is evolving awkwardly. Is there a publication
> >> which claims so? Or is this 2-bit usenet opinion? ;')
> >
> >See Plauger's comments in Embedded Systems Programming, for example.
> >(I'm not sure why an opinion in a publication is necessarily better
> >than one on the Internet, but nonetheless, there it is...)
> >
>
> I too tend to disbelieve claims that C++ is evolving awkwardly, but
> anyone who hasn't seen the <em> reams</em> of material published on
> this topic must be living under a rock! The number of articles on the
> error-proness of C++ exception handling alone could supply all the
> material for a graduate level seminar.
>
> Start out with: <quote>The Evolution of C++: Language Design in the
> Marketplace of Ideas</quote>, 1993, edited by Jim Waldo, which traces
> the history of C++ from USENIX conferences to today's most popular
> OOPL. Waldo concludes that the language at one point had a clear
> design center, but that it doesn't now.
For a contrary view see
Bjarne Stroustrup: The Design and Evolution of C++
Addison Wesley ISBN 1-201-54330-3
by and large I think the committee has done an excellent job and that
ISO C++ will be a close approximation of what I hoped for.
- Bjarne
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-06-06 0:00 ` Bjarne Stroustrup <9758-26353> 0112760
@ 1996-06-06 0:00 ` Robert Dewar
0 siblings, 0 replies; 37+ messages in thread
From: Robert Dewar @ 1996-06-06 0:00 UTC (permalink / raw)
I think it is important not to borrow ideas that seem attractive without
doing quite a bit of research to make sure that the idea is reasonable.
The complaint that the C++ design is out of control and/or is designed
by committee may be appealing to Ada fans, but just remember that lots
of people make the same (unjustified) comments about Ada.
In fact I think that in this regard the development of the two languages
is rather similar, with a strong central design, influenced, as is
certainly appropriate, by community input, but certainly not dicated
by this input.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (should be Java mis-speak)
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-05-31 0:00 ` The Right Reverend Colin James III
1996-06-02 0:00 ` Richard Riehle
[not found] ` <4omoh4$k0f@ansible.bbt.com <4ov36b$1665@watnews1.watson.ibm.com>
2 siblings, 1 reply; 37+ messages in thread
From: The Right Reverend Colin James III @ 1996-05-31 0:00 UTC (permalink / raw)
[groups trimmed to relevant *.lang. ones]
Richard Riehle <rriehle@nunic.nu.edu> posted with deletions:
| The Java code could certainly be produced by an Ada compiler or
| an Eiffel compiler, etc. No argument with that. In fact, Intermetrics
| has a product which does this, and ISE is working on an Eiffel compiler
| that will do this.
Apparently Riehle does not understand that bytecode produced by Java is
exactly what FORTH produces. (Remember that the bootstrap in Sun computers
is ROM code written in FORTH, and hence a FORTH system.)
Therefore for Ada or Eiffel to produce bytecode is silly.
If Riehle means that Ada or Eiffel produce Java code, which in turn is
compiled by Java compilers into bytecode, then that is possible but may be
a wasted abstraction because Ada or Eiffel would be better suited to
producing wrappers and interfaces to Java rather than being expensive code
generators for Java, as Riehle apparently advocates.
Riehle's general observations below make it clear that he does not
understand Java at all.
| Interpreted code is relatively easy to reverse-engineer. Consequently,
| it is harder to protect proprietary algorithms.
|
:
| One of Java's premier virtues is is portability. Another is its ease
| of use. Neither of those features should be weakened. However, both
| features make it easier to reverse-engineer applications written in
| Java. Let me emphasize that I do not see this as a bad thing.
|
| On the other hand, for publishers of commercial software products, there
| is greater security of the intellectual property for compiled code than
| for interpreted code.
|
| In many ways, Java is BASIC for the next century. In time, Java will be
| offerred as a compiled language, clever people will add new features to
| make it more secure, and others will tack on features to make it more
| incomprehensible. Already, feature-creep is beginnning to manifest
| itself as self-enlightened software gurus conclude that Java would be
| even better if it just had this one or two more features.
|
| I like Java. I hope it can survive long enough in its present form long
| enough to resist the wide-spread temptation to "make it better." Let it
| mature. Let its users mature. Then, later (much later) revisit the
| language design. One of the problems with C++ is that it is evolving
| beyond Stroustop's original vision into a collection of features in
| which seem to be on a collsion course with each other. Somehow, the
| ISO Ada 95 standard managed to improve on the ISO Ada 87 standard
| without mangling the language.
|
| Anyway, my main point is that Java's very benefits for interactive
| software are also its drawbacks for secure software. It is a simple
| trade-off. But it needs to be recognized.
|
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (should be Java mis-speak)
1996-05-31 0:00 ` Java Risks (should be Java mis-speak) The Right Reverend Colin James III
@ 1996-06-02 0:00 ` Richard Riehle
1996-06-03 0:00 ` Tucker Taft
0 siblings, 1 reply; 37+ messages in thread
From: Richard Riehle @ 1996-06-02 0:00 UTC (permalink / raw)
To: The Right Reverend Colin James III
On Fri, 31 May 1996, The Right Reverend Colin James III wrote:
Colin,
I appreciate your taking the time to post a reply to my comments.
> Richard Riehle <rriehle@nunic.nu.edu> posted with deletions:
>
> Apparently Riehle does not understand that bytecode produced by Java is
> exactly what FORTH produces. (Remember that the bootstrap in Sun computers
> is ROM code written in FORTH, and hence a FORTH system.)
I did not know that you were one of those few practitioners who is
experienced with Forth.
My memory of Forth must be a little ragged since I do not recall that
Forth produces code indentical to Java bytecode. However, I do have
a hazy recall that Forth code is relatively easy to re-engineer. Also,
if my memory is not playing tricks on me, Forth has fewer facilities
for encapsulation than Java. OTOH, Forth does allow one to create
abstractions from primitives, create new abstractions from existing
abstractions, and so on. It is a powerful language for designing on
the notion of succesive levels of abstraction.
It is new information for me that the bootstrap in the Sun Rom was written
in Forth, but it does not surprise me. Forth is particularly useful for
that kind of thing. Thanks for that littl tidbit of information.
> Therefore for Ada or Eiffel to produce bytecode is silly.
If I implied that Ada or Eiffel should produce bytecode, I apologize.
That was never my intention. However, there are already Ada products,
and, I believe, Eiffel products in development, that will generate
either Java code or some intermediate Java representation that will
ultimately be translated into bytecode.
I am not qualified to comment on the virtue of this approach, but
some of our more emminent colleagues seem to see some benefit in
it. Too soon to tell, really, whether this is appropriate or not.
> If Riehle means that Ada or Eiffel produce Java code, which in turn is
> compiled by Java compilers into bytecode, then that is possible but may be
> a wasted abstraction because Ada or Eiffel would be better suited to
> producing wrappers and interfaces to Java rather than being expensive code
> generators for Java, as Riehle apparently advocates.
As noted in my repsonse to your previous paragraph, this is exactly what
some software publishers are doing. Make sense? I have no idea. But it
is interesting that such products are emerging in the marketplace. It
also enhances the long-term credibility of Java.
> Riehle's general observations below make it clear that he does not
> understand Java at all.
I defer to your superior knowledge on this subject. My study of Java
has been limited to reading two books and about a dozen articles. So
far, I have not written any Java applets. It is my intention to do so
in the not too distant future, but you are clearly ahead of me on this.
> | Interpreted code is relatively easy to reverse-engineer. Consequently,
> | it is harder to protect proprietary algorithms.
If, indeed, Java is interpreted rather than compiled, I stand by this.
OTOH, if bytecode is somehow better protected than I suggest, I am
willing to acknowledge the error of my ways.
I have been wrong many times before. I expect to be wrong many times
in the future. This is one of those times I would rather be wrong.
However, my comments regarding the requirement for the protection of
intellectual property in published software, in the paragraphs that
followed this, highlight concerns shared by most software publshers
who have an interest in protecting their investment.
As a publisher of software, I know you also have some concerns about
this issue.
The overriding question, regarding Java, is, if we develop proprietary
software in this language, license that software through some commercial
distribution channel, and hope to remain competitive, will our more
resourceful competitors find us easy targets?
Robert Dewar, in a separate communication on this topic, makes a
compelling argument in favor of Java's safety. I think it is still
an open question.
Once again, Colin, thanks for your observations on this issue.
Richard Riehle
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (should be Java mis-speak)
1996-06-02 0:00 ` Richard Riehle
@ 1996-06-03 0:00 ` Tucker Taft
0 siblings, 0 replies; 37+ messages in thread
From: Tucker Taft @ 1996-06-03 0:00 UTC (permalink / raw)
Richard Riehle (rriehle@nunic.nu.edu) wrote:
: On Fri, 31 May 1996, The Right Reverend Colin James III wrote:
: Colin,
: I appreciate your taking the time to post a reply to my comments.
: > Richard Riehle <rriehle@nunic.nu.edu> posted with deletions:
: >
: > Apparently Riehle does not understand that bytecode produced by Java is
: > exactly what FORTH produces.
The Java bytecode and the FORTH representation are not "exactly" the same.
In fact, FORTH generally uses a "word" code rather than a byte code.
The Java byte code and the FORTH word-code have some common goals,
but the details are all quite different.
: > Therefore for Ada or Eiffel to produce bytecode is silly.
: If I implied that Ada or Eiffel should produce bytecode, I apologize.
: That was never my intention. However, there are already Ada products,
: and, I believe, Eiffel products in development, that will generate
: either Java code or some intermediate Java representation that will
: ultimately be translated into bytecode.
Our Ada/Java product ("AppletMagic(r)") generates Java-compatible
byte codes directly, with no intermediate steps. Java byte-codes are
stored in ".class" files. The output of AppletMagic, just like
the output of Sun's Java compiler, is one or more ".class"
files, containing byte-codes to represent methods, and other information
to provide the symbol table information necessary to support
dynamic linking.
The Java byte-code/".class"-file format, although designed to support
Java, is not inherently dependent on the "surface syntax" used to
write a program. The semantics of languages like Modula-3, Ada 95,
Oberon-2, etc., are all quite directly representable in Java byte codes.
Eiffel would be a bit more of a challenge, given its heavy dependence
on multiple inheritance of implementation, though it could probably
be done with some appropriate mapping.
In any case, by generating a Java-compatible ".class" file, AppletMagic
allows the Ada 95 programmer to create the same kind of platform independent,
browser-executable applets as one can create using a Java compiler,
and to call back and forth between Ada95 and Java code.
There is a lot of information available on Java (see www.javasoft.com),
as well as on our Ada => Java-byte-code compiler
(see www.inmet.com/javadir/download). There is no need to
speculate...
: ...
: Richard Riehle
-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/
Intermetrics, Inc. Cambridge, MA USA
^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <4omoh4$k0f@ansible.bbt.com <4ov36b$1665@watnews1.watson.ibm.com>]
* Re: Java Risks (Was: Ada News Brief - 96-05-24
[not found] ` <4omoh4$k0f@ansible.bbt.com <4ov36b$1665@watnews1.watson.ibm.com>
@ 1996-06-04 0:00 ` Richard Riehle
0 siblings, 0 replies; 37+ messages in thread
From: Richard Riehle @ 1996-06-04 0:00 UTC (permalink / raw)
To: Norman H. Cohen
Norman,
As you know, I am no advocate of the virtues of C++. However, I do
believe that, if one needed to extend C into a OOP language, the
decision taken by Stroustrop was, if not brilliant (I do tend to
hyperbole sometimes), at least intelligent.
The fact that it can lead to kind of absurdities illustrated in your
response, does not diminish the intelligence of the idea. It simply
shows that there are ways to corrupt it through misuse. My position
vis a vis C++ has been that it is not well-suited to the development of
software that must work with consistent reliabilty. And you have shown
an example to support that view. It is unfortunate that C++ is so
vulnerable to exposure from such examples. And it gets worse as new
features are added. In particular, the exception handling in C++ is
a rather sad sight to behold.
On 3 Jun 1996, Norman H. Cohen wrote:
> In article <Pine.GSO.3.92.960602134300.12386C-100000@nunic.nu.edu>,
> Richard Riehle <rriehle@nunic.nu.edu> writes:
>
> |> There are aspects of C++ that, as orginally conceived by Dr.
> |> Stroustrup, make very good sense. The fundamental idea of
> |> expanding the stuct into a class was a stroke of brilliance.
>
> I disagree. It is the confusion of classes and structs (along with the
> confusion of class-as-type-definition and class-as-module) that leads to
> absurdities such as the following:
>
> class C {
> protected:
> typedef ... T;
> static T x; // perfectly legal
> struct S {
> T x; // illegal: protected "member" T inaccessible inside
> } y; // a struct, despite nesting.
> }
OK, so my langauge is a little exagerrated sometimes. I do think it was
kind of a smart idea, even though it does lend itself to the kind of
corrupt thinking illustrated in this example. In all honesty, very few
C++ programmers would design a class with such an obviously ugly
profile.
All in all, thanks for a rather amusing example, though.
Richard Riehle
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada News Brief - 96-05-24.txt [1/1]
1996-05-24 0:00 Ada News Brief - 96-05-24.txt [1/1] AdaIC
1996-05-27 0:00 ` Tucker Taft
@ 1996-05-27 0:00 ` Brian Rogoff
1996-05-31 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 Jon S Anthony
` (4 subsequent siblings)
6 siblings, 0 replies; 37+ messages in thread
From: Brian Rogoff @ 1996-05-27 0:00 UTC (permalink / raw)
stt@henning.camb.inmet.com (Tucker Taft) writes:
AdaIC (adainfo@sw-eng.falls-church.va.us) wrote:
: Ada News Brief
: Week Ending: May 24, 1996
: ... Tucker Taft, chief scientist of Intermetrics, Inc.,
: stated, "Of course they would love to see Java as the next
: Ada in DoD. It's a lot of hype.
^^^^^^^^^^^^^^^^^^^ This is either a misquote,
or taken out of context. I am a fan of Java, and I don't think it
is just a lot of hype.
But the statement that Java will replace Ada (or C++) in all applications
is probably hype, right? That is how I read that response.
Be that as it may, I do believe Ada has a number of
advantages, particularly with respect to the thoroughness
of the compile-time checking provided by Ada (e.g. strong type
distinctions between numeric types, enumeration types, array types,
etc.). For example, Java treats all "int"s as freely interconvertible,
and has no separate concept of an enumeration type. This means that a
Java interface communicates less information than an Ada interface, both
to the reader, and to the compiler.
Ada has a number of advantages in "close to the metal" programming as well.
The great thing about the Ada/Java combination is that we get the
best of both worlds, getting the robust consistency checking, generic
templates, enumeration types, etc., from the Ada side, while also
getting garbage collection, dynamic linking, Web-browser integration, etc.
from the Java side.
I guess you mean that you like the JVM, and not the Java language.
There is a proposal from MIT to add parametrized types to Java. It was posted
in the Java newsgroup recently. They also talk about adding iterators,
closures, and a few more goodies. I think those additions would go a long
way towards closing the gap with Ada, Eiffel, and other languages.
-- Brian
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-05-24 0:00 Ada News Brief - 96-05-24.txt [1/1] AdaIC
1996-05-27 0:00 ` Tucker Taft
1996-05-27 0:00 ` Ada News Brief - 96-05-24.txt [1/1] Brian Rogoff
@ 1996-05-31 0:00 ` Jon S Anthony
1996-06-01 0:00 ` Java Risks David Hopwood
1996-06-02 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 Richard Riehle
1996-06-01 0:00 ` Bob Crispen
` (3 subsequent siblings)
6 siblings, 2 replies; 37+ messages in thread
From: Jon S Anthony @ 1996-05-31 0:00 UTC (permalink / raw)
In article <Pine.GSO.3.92.960530095503.21075A-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:
> > Although there are many Java interpreters and Ada compilers, neither
> > the Java language nor the Ada language impose a particular model of
> > program execution (compiler, interpreter, distribution, etc.)
>
> I think you may have identified a key difference in the opening
> lines of the preceding paragraph. Compiled source code is usually
> optimized, and passed through other processes (linkers, binders, etc.)
> which makes applications a bit more difficult to unravel back to their
> original source code. Ada adds an additional layer in the form of an
> RTE which varies from one compiler publisher to another.
Sorry, this just plain does not make any sense. All languages add an RTE,
including (and in some sense, especially) Java. What do you think the JVM
is???
> Interpreted code is relatively easy to reverse-engineer. Consequently,
> it is harder to protect proprietary algorithms.
Really? Presumably this is relative to machine code, but it is just
plain not true. If for no other reason than one implementation's
"interpreted" code could become another's "machine" code. This
actually happened with P-code and there has even been some talk about
it with respect to J-code. 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.
> > Saying that one language has a greater risk in disclosing intellectual
> > property is just as misleading than saying that one language is more
> > efficient than another. These are properties of the programming and
> > execution environment, not of the language itself. I don't see why
> > choosing Ada or Java should make a difference here.
>
> One of Java's premier virtues is is portability. Another is its ease
> of use. Neither of those features should be weakened. However, both
> features make it easier to reverse-engineer applications written in
> Java. Let me emphasize that I do not see this as a bad thing.
He's right. In this respect there is absolutely no difference. I
have Ada code that ports without changing a single character between
VMS, UNI*, and Win/NT. With no "preprocessor" crap either. The same
code. That's pretty damn portable. I could also just use AdaMagic
and get the exact same portability you mention via J-code/JVM as Java.
Really, Richard, you are completely in the weeds here.
> Anyway, my main point is that Java's very benefits for interactive
> software are also its drawbacks for secure software. It is a simple
> trade-off. But it needs to be recognized.
Yes, I think we understand that is your point, it's just that it is
completely wrong.
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks
1996-05-31 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 Jon S Anthony
@ 1996-06-01 0:00 ` David Hopwood
1996-06-02 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 Richard Riehle
1 sibling, 0 replies; 37+ messages in thread
From: David Hopwood @ 1996-06-01 0:00 UTC (permalink / raw)
In article <JSA.96May31144955@organon.com>,
Jon S Anthony <jsa@organon.com> wrote:
>In article <Pine.GSO.3.92.960530095503.21075A-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:
>> > Although there are many Java interpreters and Ada compilers, neither
>> > the Java language nor the Ada language impose a particular model of
>> > program execution (compiler, interpreter, distribution, etc.)
Correct.
>> Interpreted code is relatively easy to reverse-engineer. Consequently,
>> it is harder to protect proprietary algorithms.
>
>Really? Presumably this is relative to machine code, but it is just
>plain not true.
Actually, I've reverse engineered JVM code and 80x86 code (for mostly-
legitimate reasons), and JVM code is considerably easier. This is mainly
because the structure of each class is exposed in the classfile format,
and also because you can easily replace classes individually.
OTOH, the difference is simply in the degree of obscurity, not in whether
reverse engineering is possible.
David Hopwood
david.hopwood@lmh.ox.ac.uk
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-05-31 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 Jon S Anthony
1996-06-01 0:00 ` Java Risks David Hopwood
@ 1996-06-02 0:00 ` Richard Riehle
1 sibling, 0 replies; 37+ messages in thread
From: Richard Riehle @ 1996-06-02 0:00 UTC (permalink / raw)
To: Jon S Anthony
I realize that I am out on a limb with this thread. But it may be worth
exploring just a little further.
On 31 May 1996, Jon S Anthony wrote:
> Sorry, this just plain does not make any sense. 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.
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.
In certain Pacific-Rim countries, software piracy is a way-of-life; at
least a way of doing business. Anyone who believes that this is going
to change is dreaming, or needs to change brands of peanut butter. Any
model for the sale and distribution of commercial software that fails
to acknowledged this fact, will have to endure its consequences.
Additionally, the more a competitor can learn about the internal
structure of your application, the easier it will be to make incremental
improvements and being them to market quickly. If this were only
a domestic U.S. issue, we would simply engage the services of the hordes
of underemployed lawyers.
> > Interpreted code is relatively easy to reverse-engineer. Consequently,
> > it is harder to protect proprietary algorithms.
> Really? Presumably this is relative to machine code, but it is just
> plain not true. If for no other reason than one implementation's
> "interpreted" code could become another's "machine" code.
I agree with the latter sentence. However, bytecode is interpreted as
if it were a kind of universal machine code. All one needs is a
bytecode intepreter. Historically, machine code programs have been
translated or emulated so they will run on new hardware. This is
usually not as efficient as running in native mode. If one writes
a native mode bytecode interpreter, I would guess that there would
be a somewhat more satisfactory outcome.
> This
> 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.
> 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?
> > > Saying that one language has a greater risk in disclosing intellectual
> > > property is just as misleading than saying that one language is more
> > > efficient than another.
This analogy does not hold. It is close to an apples and oranges thing.
> > One of Java's premier virtues is is portability.
> He's right. In this respect there is absolutely no difference. I
> have Ada code that ports without changing a single character between
> VMS, UNI*, and Win/NT. With no "preprocessor" crap either. The same
> code. That's pretty damn portable. I could also just use AdaMagic
> and get the exact same portability you mention via J-code/JVM as Java.
> Really, Richard, you are completely in the weeds here.
Still not the same thing. You cannot port your executable Ada program
from VMS to Win/NT. Once I publish an application and license it to
you for your Win/NT, I defy you to execute it, without considerable
trouble, on a VMS machine.
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 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?
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.
Richard Riehle
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-05-24 0:00 Ada News Brief - 96-05-24.txt [1/1] AdaIC
` (2 preceding siblings ...)
1996-05-31 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 Jon S Anthony
@ 1996-06-01 0:00 ` Bob Crispen
1996-06-05 0:00 ` Alan Brain
1996-06-03 0:00 ` Norman H. Cohen
` (2 subsequent siblings)
6 siblings, 1 reply; 37+ messages in thread
From: Bob Crispen @ 1996-06-01 0:00 UTC (permalink / raw)
Jon S Anthony wrote:
>> Interpreted code is relatively easy to reverse-engineer. Consequently,
>> it is harder to protect proprietary algorithms.
>
>Really? Presumably this is relative to machine code, but it is just
>plain not true. If for no other reason than one implementation's
>"interpreted" code could become another's "machine" code.
Yup. Having written a 6809 disassembler (wonderful chip!) and a Forth
decompiler, I can state unequivocally that disassemblers are easier.
And remember, I had all the Forth environment around, so it was no trick
at all to get the name from the compiled address. But it's them ifs and
loops that getcha. And Forth is scarcely a high-level language to begin
with.
But so I don't get mistaken by Robert Dewar for the first guy who mentioned
good old Forth here, let me ask him, are you sure the JVM is threaded?
It would seem like quite a waste of processor power, especially when you
don't need to do much fancy business like single stepping in the normal
course of events. And it must be a nightmare converting addresses between
machines. One reason Forth threading was fast was that you knew the exact
address where everything was. Well I suppose I could go to the manual
and find out.
>This
>actually happened with P-code and there has even been some talk about
>it with respect to J-code. Again, this just plain makes no sense.
Ditto for Forth. Anybody remember the Forth machine? It was a little
hummer.
Bob Crispen
crispen@hiwaay.net
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-05-24 0:00 Ada News Brief - 96-05-24.txt [1/1] AdaIC
` (3 preceding siblings ...)
1996-06-01 0:00 ` Bob Crispen
@ 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-09 0:00 ` Jim Kingdon
6 siblings, 2 replies; 37+ messages in thread
From: Norman H. Cohen @ 1996-06-03 0:00 UTC (permalink / raw)
In article <Pine.GSO.3.92.960602134300.12386C-100000@nunic.nu.edu>,
Richard Riehle <rriehle@nunic.nu.edu> writes:
|> There are aspects of C++ that, as orginally conceived by Dr.
|> Stroustrup, make very good sense. The fundamental idea of
|> expanding the stuct into a class was a stroke of brilliance.
I disagree. It is the confusion of classes and structs (along with the
confusion of class-as-type-definition and class-as-module) that leads to
absurdities such as the following:
class C {
protected:
typedef ... T;
static T x; // perfectly legal
struct S {
T x; // illegal: protected "member" T inaccessible inside
} y; // a struct, despite nesting.
}
--
Norman H. Cohen ncohen@watson.ibm.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-06-03 0:00 ` Norman H. Cohen
@ 1996-06-03 0:00 ` Imonics Corporation
1996-06-07 0:00 ` Peter Wentworth
1 sibling, 0 replies; 37+ messages in thread
From: Imonics Corporation @ 1996-06-03 0:00 UTC (permalink / raw)
In article <4ov36b$1665@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>Richard Riehle <rriehle@nunic.nu.edu> writes:
>
>|> There are aspects of C++ that, as orginally conceived by Dr.
>|> Stroustrup, make very good sense. The fundamental idea of
>|> expanding the stuct into a class was a stroke of brilliance.
>
>I disagree. It is the confusion of classes and structs (along with the
>confusion of class-as-type-definition and class-as-module) that leads to
>absurdities such as the following:
<coding anomaly deleted>
>Norman H. Cohen ncohen@watson.ibm.com
I think you may have misunderstood. What I got out of the
statement was that the conceptual expansion was a stroke of
brilliance, not that the details of a C construct being expanded
into a C++ construct was.
rc
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-06-03 0:00 ` Norman H. Cohen
1996-06-03 0:00 ` Imonics Corporation
@ 1996-06-07 0:00 ` Peter Wentworth
1 sibling, 0 replies; 37+ messages in thread
From: Peter Wentworth @ 1996-06-07 0:00 UTC (permalink / raw)
In <4ov36b$1665@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:
>In article <Pine.GSO.3.92.960602134300.12386C-100000@nunic.nu.edu>,
>Richard Riehle <rriehle@nunic.nu.edu> writes:
>|> There are aspects of C++ that, as orginally conceived by Dr.
>|> Stroustrup, make very good sense. The fundamental idea of
>|> expanding the stuct into a class was a stroke of brilliance.
>I disagree. It is the confusion of classes and structs (along with the
>confusion of class-as-type-definition and class-as-module) that leads to
>absurdities such as the following:
...
With natural languages I've never had too much concern that it might
be possible to construct ambiguous or difficult-to-understand absurdities.
I don't assess the quality of a violin on the basis that some hacker
might be able to make it sound bad by getting poor interaction between
the bow and two or more strings...
But there is a pervasive idea among many Computer Scientists that
seems to assess the quality of a language in terms of whether
they can find some interesting way to abuse it. This particular
"evaluation paradigm" (and the usual text-book stuff of orthogonality
of base concepts, etc.) isn't necessarily God-given, written-in-concrete,
the one-and-only-true-way.
I think the C++ critics would get a much better hearing, at least from
me, if they tried to explain about those things they were not able to do
cleanly or elegantly (and there are probably many!). Anybody can write
rubbish in any language. So what?
Peter
--
EP Wentworth - Dept. of Comp. Sci. - Rhodes University - Grahamstown - RSA.
cspw@cs.ru.ac.za "If you come to a fork in the road, take it."
fax: +27 461 311915 Yogi Bear
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-05-24 0:00 Ada News Brief - 96-05-24.txt [1/1] AdaIC
` (4 preceding siblings ...)
1996-06-03 0:00 ` Norman H. Cohen
@ 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
6 siblings, 2 replies; 37+ messages in thread
From: Norman H. Cohen @ 1996-06-05 0:00 UTC (permalink / raw)
In article <Pine.GSO.3.92.960604155403.19912B-100000@nunic.nu.edu>,
Richard Riehle <rriehle@nunic.nu.edu> writes:
|> > class C {
|> > protected:
|> > typedef ... T;
|> > static T x; // perfectly legal
|> > struct S {
|> > T x; // illegal: protected "member" T inaccessible inside
|> > } y; // a struct, despite nesting.
|> > }
...
|> In all honesty, very few
|> C++ programmers would design a class with such an obviously ugly
|> profile.
But it's not an ugly profile, it's a perfectly reasonable idiom. S and T
are strictly part of the implementation of class C, so the programmer
wants to keep them hidden in protected declarations. The C++ code above
is the direct analog of the following Ada code:
package C is
type C_Type is private;
...
private
type T is ...;
type S is
record
x: T; -- T is usable here even though hidden outside
-- of package C.
...
end record;
type C_Type is
record
y: S;
...
end record;
end C;
package body C is
...
x: T; -- Corresponds to the C++ static member above, but is hidden
-- in the package body, where it belongs.
...
end C;
As an aside, here's the latest C/C++ pitfall to bite me:
*** Error: Mixed metaphor. ^^^^^^^ ^^^^
char * six_string_guitar[6] =
{ "E string",
"A string",
"D string"
"G string",
"B string",
"E string"
};
Because of the missing comma following "D string" (did you notice it?),
six_string_guitar is actually quietly initialized to {"E string",
"A string", "D stringG string", "B string", "E string", 0}. (Adjacent
string constants are concatenated, and default values--zero in the case
of a pointer--are used for missing elements in an initializer.) What a
language!
--
Norman H. Cohen ncohen@watson.ibm.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-06-05 0:00 ` Norman H. Cohen
@ 1996-06-05 0:00 ` Bill Brennamw
1996-06-08 0:00 ` Brian N. Miller
1 sibling, 0 replies; 37+ messages in thread
From: Bill Brennamw @ 1996-06-05 0:00 UTC (permalink / raw)
In article <4p44m2$tc5@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>As an aside, here's the latest C/C++ pitfall to bite me:
>*** Error: Mixed metaphor. ^^^^^^^ ^^^^
Of course you meant "pitbull to bite me".
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-06-05 0:00 ` Norman H. Cohen
1996-06-05 0:00 ` Bill Brennamw
@ 1996-06-08 0:00 ` Brian N. Miller
1 sibling, 0 replies; 37+ messages in thread
From: Brian N. Miller @ 1996-06-08 0:00 UTC (permalink / raw)
In article <4p44m2$tc5@watnews1.watson.ibm.com>, ncohen@watson.ibm.com says...
>
>Here's the latest C/C++ pitfall to bite me:
>
> char * six_string_guitar[6] =
> { "E string",
> "A string",
> "D string"
> "G string",
> "B string",
> "E string"
> };
>
>Because of the missing comma following "D string" (did you notice it?),
>six_string_guitar is actually quietly initialized to {"E string",
>"A string", "D stringG string", "B string", "E string", 0}.
How about this one which prints nothing because mispelled 'default:'
is treated as a goto label:
enum {red,white,blue} color = white;
switch (color) {
case red: printf("red"); break;
case blue: printf("blue"); /* Fall thru */
defualt: printf("blue or other color");
};
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-05-24 0:00 Ada News Brief - 96-05-24.txt [1/1] AdaIC
` (5 preceding siblings ...)
1996-06-05 0:00 ` Norman H. Cohen
@ 1996-06-09 0:00 ` Jim Kingdon
6 siblings, 0 replies; 37+ messages in thread
From: Jim Kingdon @ 1996-06-09 0:00 UTC (permalink / raw)
(I probably have something better to do than following up, but....)
How about this one which prints nothing because mispelled 'default:'
is treated as a goto label:
enum {red,white,blue} color = white;
switch (color) {
case red: printf("red"); break;
case blue: printf("blue"); /* Fall thru */
defualt: printf("blue or other color");
};
My compiler catches this:
bash$ gcc -Wall def.c
def.c: In function `main':
def.c:9: warning: enumeration value `white' not handled in switch
def.c:8: warning: label `defualt' defined but not used
bash$
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
@ 1996-06-03 0:00 Jon S Anthony
0 siblings, 0 replies; 37+ messages in thread
From: Jon S Anthony @ 1996-06-03 0:00 UTC (permalink / 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
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~1996-06-09 0:00 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` Robert Dewar
1996-06-01 0:00 ` AdaWorks
1996-06-01 0:00 ` Robert Dewar
1996-06-01 0:00 ` AdaWorks
1996-06-01 0:00 ` Robert Dewar
1996-06-01 0:00 ` Mike Young
1996-06-03 0:00 ` Robert Dewar
1996-06-04 0:00 ` Richard Riehle
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
1996-05-31 0:00 ` Java Risks (should be Java mis-speak) The Right Reverend Colin James III
1996-06-02 0:00 ` Richard Riehle
1996-06-03 0:00 ` Tucker Taft
[not found] ` <4omoh4$k0f@ansible.bbt.com <4ov36b$1665@watnews1.watson.ibm.com>
1996-06-04 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 Richard Riehle
1996-05-27 0:00 ` Ada News Brief - 96-05-24.txt [1/1] Brian Rogoff
1996-05-31 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 Jon S Anthony
1996-06-01 0:00 ` Java Risks David Hopwood
1996-06-02 0:00 ` Java Risks (Was: Ada News Brief - 96-05-24 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
-- strict thread matches above, loose matches on Subject: below --
1996-06-03 0:00 Jon S Anthony
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox