Ada News Brief - 96-05-24.txt [1/1]

Ada News Brief - 96-05-24.txt [1/1]

[AdaIC]

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.

Re: Ada News Brief - 96-05-24.txt [1/1]

[Tucker Taft]

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

Re: Ada News Brief - 96-05-24.txt [1/1]

[Brian Rogoff]

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

Re: Ada News Brief - 96-05-24.txt [1/1]

[Richard Riehle]

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

Re: Ada News Brief - 96-05-24.txt [1/1]

[Andreas Zeller]

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

Re: Ada News Brief - 96-05-24.txt [1/1]

[Robert Dewar]

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!

Java Risks (Was: Ada News Brief - 96-05-24

[Richard Riehle]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Brian N. Miller]

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?  ;')

Re: Java Risks (should be Java mis-speak)

[The Right Reverend Colin James III]

 [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.
| 

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Jon S Anthony]

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

Re: Java Risks

[David Hopwood]

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

Re: Ada News Brief - 96-05-24.txt [1/1]

[Robert Dewar]

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.

Re: Ada News Brief - 96-05-24.txt [1/1]

[Robert Dewar]

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).

Re: Ada News Brief - 96-05-24.txt [1/1]

[Mike Young]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Bob Crispen]

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

Re: Ada News Brief - 96-05-24.txt [1/1]

[AdaWorks]

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

Re: Ada News Brief - 96-05-24.txt [1/1]

[AdaWorks]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Richard Riehle]

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

Re: Java Risks (should be Java mis-speak)

[Richard Riehle]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Richard Riehle]

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

Re: Ada News Brief - 96-05-24.txt [1/1]

[Robert Dewar]

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.

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Ken Garlington]

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"

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Norman H. Cohen]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Imonics Corporation]

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

Re: Java Risks (should be Java mis-speak)

[Tucker Taft]

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

Re: Ada News Brief - 96-05-24.txt [1/1]

[Richard Riehle]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Richard Riehle]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Bill Brooks]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Norman H. Cohen]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Bill Brennamw]

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".

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Alan Brain]

Bob Crispen <crispen@hiwaay.net> wrote:

>Ditto for Forth.  Anybody remember the Forth machine?  It was a little
>hummer.

No, but my Exidy Sorcerer, with a whopping 32K after I put in more memory chips, had 
a FORTH RomPac added soon after purchase. Vintage 1979.

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Bjarne Stroustrup <9758-26353> 0112760]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Robert Dewar]

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.

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Peter Wentworth]

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

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Brian N. Miller]

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");
};

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Jim Kingdon]

(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$