* Re: Java Risks (Was: Ada News Brief - 96-05-24
@ 1996-06-03 0:00 Jon S Anthony
0 siblings, 0 replies; 20+ 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] 20+ messages in thread
* Ada News Brief - 96-05-24.txt [1/1]
@ 1996-05-24 0:00 AdaIC
1996-05-27 0:00 ` Tucker Taft
` (5 more replies)
0 siblings, 6 replies; 20+ 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] 20+ 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-31 0:00 ` Jon S Anthony
` (4 subsequent siblings)
5 siblings, 1 reply; 20+ 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] 20+ 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; 20+ 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] 20+ 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 ` Java Risks (Was: Ada News Brief - 96-05-24 Richard Riehle
0 siblings, 1 reply; 20+ 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] 20+ messages in thread
* Java Risks (Was: Ada News Brief - 96-05-24
1996-05-29 0:00 ` Andreas Zeller
@ 1996-05-30 0:00 ` Richard Riehle
1996-05-31 0:00 ` Brian N. Miller
[not found] ` <4omoh4$k0f@ansible.bbt.com <4ov36b$1665@watnews1.watson.ibm.com>
0 siblings, 2 replies; 20+ 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] 20+ 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
[not found] ` <4omoh4$k0f@ansible.bbt.com <4ov36b$1665@watnews1.watson.ibm.com>
1 sibling, 2 replies; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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-31 0:00 ` Jon S Anthony
1996-06-02 0:00 ` Richard Riehle
1996-06-01 0:00 ` Bob Crispen
` (3 subsequent siblings)
5 siblings, 1 reply; 20+ 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] 20+ messages in thread
* Re: Java Risks (Was: Ada News Brief - 96-05-24
1996-05-31 0:00 ` Jon S Anthony
@ 1996-06-02 0:00 ` Richard Riehle
0 siblings, 0 replies; 20+ 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] 20+ 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-31 0:00 ` 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)
5 siblings, 1 reply; 20+ 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] 20+ 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-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
5 siblings, 2 replies; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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-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
5 siblings, 2 replies; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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-05 0:00 ` Norman H. Cohen
@ 1996-06-09 0:00 ` Jim Kingdon
5 siblings, 0 replies; 20+ 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] 20+ messages in thread
end of thread, other threads:[~1996-06-09 0:00 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-06-03 0:00 Java Risks (Was: Ada News Brief - 96-05-24 Jon S Anthony
-- 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox