The Joy of Java

> "Krakatoa--East of Java"

An excellent Rant in which our Titular Leader, Tim May, sings the
praises of Java and denounces an evil sect of Crypto Separatists,
the self-described "Coderpunks."

 > Well, I was not invited to join the elite and secret
 > coderpunks list, but I still have some thoughts on coding
 > and, especially, on the opportunities offered by Java. Sorry
 > if this interferes with discussions of Rabbi Heir and Morris
 > Dees.

Given the various parameters which determine the life and death
of mailing lists, I fully expect Coderpunks to become moribund
within six months, and its members to reunify with this list.

Very few of these "I'm going to start my own list with less
noise" adventures ever make it long term, absent the
personalities and critical mass of interesting information which
drove the list they spun off from.

 > 1. Java is of course not a perfect language, nor even the
 > best for specific applications. Other languages will
 > continue to thrive. Critics of the language and related
 > items (applet model, JDK, JITs, etc.) may point to various
 > problems (e.g. security).

 > 2. However, the "big picture" is compelling. Java arrives
 > at a time when a Babel of languages and platforms threatens
 > interoperability. C++ is despised by many (though, to be
 > fair, liked by many, too), and developers are adopting
 > Visual Basic (and the vbx widgets, etc.), PowerBuilder,
 > Delphi, flavors of Smalltalk (no pun intended), and
 > scripting languages (Perl, TCL, Python, etc.).

I completely agree with this.  Java incorporates the type of
automatic corruption-proof memory management found in languages
like APL, the basic notions of object oriented programming, fast
dynamic linking, and a C-like program structure.

This is powerful combination of features and gives Java the
potential to do all the platform-independent things that were
advertised for C before the rude reality of thousand line
makefiles reared its ugly head. . The complete specification of
the Java Virtual Machine means that the behavior of Java programs
is perfectly well-defined, and one does not have to tweek
anything which is processor or operating system dependent.

In the future, I expect Java bytecode to become a significant
channel for the distribution of popular applications, with
compilation to fast native code on numerous platforms.

Java is clean, and its concepts are easily understandable even by
persons whose eyes glaze over after the first 30 pages of the C++
manual.

 > 4. What is so compelling, to me, is that Java programs have
 > an excellent chance of running on various flavors of Unix,
 > on Windows-95 and NT systems, on Macs, and on other systems
 > without changes, and without any special compilers bought by
 > the users! (Netscape browsers, and even Microsoft browsers,
 > are able to view applets, or soon will be. And cheap or free
 > applet viewers are available.)

Expect NT to be a Unix-killer in the future.  It can be ported to
any machine, and its microkernel client-server design with
pluggable third-party APIs permits it to manifest simultaneously
the personalities of numerous different operating systems.
Contrast this with the many different binary incompatible Unix
flavors and its marketing advantage becomes clear.  NT sales just
broke one billion per year and are climbing steadily.

NT and Java will be the big players in the future.  If Netscape
becomes its own OS, requiring no Microsoft software, it will
probably capture the low-end "Web TV" market.

 > 6. One can imagine several applets of interest to
 > Cypherpunks. The ability to fairly transparently run them on
 > multiple platforms, effectively bypassing the platform
 > dependencies, is very important. Check out Hal Finney's site
 > for some "crytographic primitive" applets he's written.

Indeed.  One can imagine a nice set of Java classes and methods
which interoperates with PGP, and has none of the fixed buffer
allocation, limits, and awkward memory management present in PGP.
Java tends to do the kinds of things PGP does very cleanly, and
implementors can worry about the algorithms without being
distracted by housekeeping.  Any code produced can instantly be
used by others in their applications.  This is a powerful
paradigm, encourages others to expand on existing work, and
renders kludges like "PGPTools" unnecessary.

 > 10. "Mindshare" is the real story. Java arrives at the
 > right time. Cypherpunks needs--those needs that go beyond
 > just the "sealed envelopes and signatures" level which PGP
 > provides so well--are likely to fit in with this Net-centric
 > communications model. (I'm already thinking in terms of Java
 > applets for building blocks for Cypherpunk sorts of things.)

Java Applets, mobile crypto agents, and the new Web-centric view
of cyberspace will go a long way towards encouraging the
planet-wide use of strong crypto, as well as effectively swatting
annoying mosquitos like ITAR.

Indeed, with Java, I can put up a Web page which teaches someone
about a cryptographic algorithm, allows him to try it out and run
sample data through it, and provides him with a
platform-independent implementation of it to use as he wishes.
All in one fell swoop.  That's a pretty powerful concept.

Java has come at the right time, and it will produce chaotic
change in the existing order.

Should be interesting.

--
     Mike Duvos         $    PGP 2.6 Public Key available     $
     mpd@netcom.com     $    via Finger.                      $

On Thu, 25 Apr 1996, Mike Duvos wrote:

> Given the various parameters which determine the life and death
> of mailing lists, I fully expect Coderpunks to become moribund
> within six months, and its members to reunify with this list.
> 
> Very few of these "I'm going to start my own list with less
> noise" adventures ever make it long term, absent the
> personalities and critical mass of interesting information which
> drove the list they spun off from.

In this case, I hope not. There are people (not myself) who only want 
the coding-related material arriving in their mailboxes. Coderpunks 
serves that need. I think that particular list is more of a filter than a 
separate list. If you look at the archives (if they come back up) you'll
see a few crypto bigwigs on coderpunks that haven't seen fit to post to 
cypherpunks in a very long time, if ever. It'd be nice to keep 
receiving their input without forcing them into tedious killfiling measures.
Conversely, I don't see why the activists should have to deal with code.

The main list, imho, has mostly become something of a watering hole for 
the primary crypto user community. Something quite different from the usenet 
crypto groups.

And since the list is very active regardless of signal, it will still be 
a place to send out some signal on those occasions where the important 
thngs occur. They don't (and can't) every day. And usenet just doesn't 
perform this function properly. 

I really do think having archives alongside a cypherpunks archive is crucial
for the survival of an offshoot list. Institutional memory is very 
useful, especially for time-insensitive things like technical discussions.
If hks decides not to bring back the archives, I hope they tell us promptly
and temporarily put the whole thing up for ftp so someone else can 
provide this valuable service. (Kudos to hks and Todd for having given to us 
up till now.)

It's safe for you to unsubscribe now, Perry.

Mike Duvos writes:
> > 1. Java is of course not a perfect language, nor even the
> > best for specific applications. Other languages will
> > continue to thrive. Critics of the language and related
> > items (applet model, JDK, JITs, etc.) may point to various
> > problems (e.g. security).
>
> > 2. However, the "big picture" is compelling. Java arrives
> > at a time when a Babel of languages and platforms threatens
> > interoperability. C++ is despised by many (though, to be
> > fair, liked by many, too), and developers are adopting
> > Visual Basic (and the vbx widgets, etc.), PowerBuilder,
> > Delphi, flavors of Smalltalk (no pun intended), and
> > scripting languages (Perl, TCL, Python, etc.).
>
>I completely agree with this.  Java incorporates the type of
>automatic corruption-proof memory management found in languages
>like APL, the basic notions of object oriented programming, fast
>dynamic linking, and a C-like program structure.
>
>This is powerful combination of features and gives Java the
>potential to do all the platform-independent things that were
>advertised for C before the rude reality of thousand line
>makefiles reared its ugly head. . The complete specification of
>the Java Virtual Machine means that the behavior of Java programs
>is perfectly well-defined, and one does not have to tweek
>anything which is processor or operating system dependent.

Unfortunately, this last statement isn't really true.  To quote from the
"Java Security" paper from some Princeton researchers:

    The Java language has neighter a formal semantics nor a formal
    description of its type system.  We do not know what a Java program
    means, in any formal sense, so we cannot reason formally about Java
    and the security properties of the Java libraries written in Java.
    Java lacks a formal description of its type system, yet the security
    of Java relies on the soundness of its type system.

And later:

    The Java bytecode is where the security properties must ultimately
    be verified . . . .  Unfortunately, it is rather difficult to verify
    the bytecode. . . .  The present type verifier cannot be proven
    correct, because there is not a formal description of the type
    system.  Object-oriented type systems are a current research topic;
    it seems unwise for the system's security to rely on such a
    mechanism without a strong theoretical foundation.  It is not
    certain that an informally specified system as large and complicated
    as Java bytecode is consistent.

And in the conclusions:

    We conclude that the Java system in its current form cannot easily
    be made secure.  Significant redesign of the language, the bytecode
    format, and the runtime system appear to be necessary steps toward
    building a higher-assurance system. . . . Execution of remotely-
    loaded code is a relatively new phenomenon, and more work is
    required to make it safe.

I do think that the ideas embodied in Java are very important, and will
significantly shape the future of computing, but Java itself may be just
a stepping stone on the way.

Scott Brickner writes:
> Unfortunately, this last statement isn't really true.  To quote from the
> "Java Security" paper from some Princeton researchers:
> 
>     The Java language has neighter a formal semantics nor a formal
>     description of its type system.  We do not know what a Java program
>     means, in any formal sense, so we cannot reason formally about Java
>     and the security properties of the Java libraries written in Java.
>     Java lacks a formal description of its type system, yet the security
>     of Java relies on the soundness of its type system.

I will point out that complete formal semantics exist for other,
perfectly practical to use languages, like Scheme.

>     We conclude that the Java system in its current form cannot easily
>     be made secure.  Significant redesign of the language, the bytecode
>     format, and the runtime system appear to be necessary steps toward
>     building a higher-assurance system. . . . Execution of remotely-
>     loaded code is a relatively new phenomenon, and more work is
>     required to make it safe.
> 
> I do think that the ideas embodied in Java are very important, and will
> significantly shape the future of computing, but Java itself may be just
> a stepping stone on the way.

I go further. Java, as envisioned, cannot be made secure. It is too
powerful a language. Furthermore, it is unnecessary for the tasks that
it is used for, which are basically adding fancy wacky graphics and
simple applications and such to web pages.

Perry

> 
> I go further. Java, as envisioned, cannot be made secure. It is too
> powerful a language. Furthermore, it is unnecessary for the tasks that
> it is used for, which are basically adding fancy wacky graphics and
> simple applications and such to web pages.
> 

	Even though that is all it is used for now, I think it was
*intended* to be used for more.


-- 
Sameer Parekh					Voice:   510-601-9777x3
Community ConneXion, Inc.			FAX:     510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.net/ (or login as "guest")		sameer@c2.net

sameer@c2.org writes:
>> I go further. Java, as envisioned, cannot be made secure. It is too
>> powerful a language. Furthermore, it is unnecessary for the tasks that
>> it is used for, which are basically adding fancy wacky graphics and
>> simple applications and such to web pages.
>> 
>
>	Even though that is all it is used for now, I think it was
>*intended* to be used for more.

True.  It's still lacking a couple of (non-language) features.  The
most important (and most cpunks relevant) is a mechanism to pay people
to run programs for you.  This sort of thing is dangerous without a
safe environment.  If it was safe to do so, I can see about two hundred
PowerPC systems from where I sit that are idle 90% or more.  As more
users become permanently connected to the net (cable modems and such),
there will be *millions* of computers with a little processing power
each that are available for distributed tasks.

The next generation of "Toy Story" just might be done in near real-
time.

Scott Brickner writes:
> True.  It's still lacking a couple of (non-language) features.  The
> most important (and most cpunks relevant) is a mechanism to pay people
> to run programs for you.  This sort of thing is dangerous without a
> safe environment.

You can do that safely without making it dangerous for your machine. I
know how I would build a restricted execution environment for such
markets. However, Java is 1) too slow, since if you are selling
rendering cycles or such you don't want to be running an interpreter,
2) insufficently safe, and 3) paradoxically, insufficiently powerful
for the sort of code you would want to run in such an environment.

Perry

Perry writes: 

  You can do that safely without making it dangerous for your machine. I
  know how I would build a restricted execution environment for such
  markets. However, Java is 1) too slow, since if you are selling rendering
  cycles or such you don't want to be running an interpreter, 2)
  insufficently safe, and 3) paradoxically, insufficiently powerful for the
  sort of code you would want to run in such an environment. 

What solution is fast enough and safe enough and powerful enough?  Does
such a solution exist?  I say, No, it doesn't.  So let's quit pretending
that the Holy Grail exists, and get back to engineering. 

But let's not have a food fight.  Although entertaining in the short term,
food fights are actually deathly boring and incredibly unfruitful in the
long term.  I'm interested in helping people do interesting things in a
reasonably secure way, on the internet, using Java.  We're working on a
response to the Felten el al. paper, which will be posted to the net
shortly.  I think some of their points are perfectly valid, some of their
points are irrelevant, and a lot of the presentation is melodramatic. 
Melodrama is good for sound bites, I guess. 

Marianne
working on Java security stuff at Sun

Marianne Mueller writes:
> Perry writes: 
> 
>   You can do that safely without making it dangerous for your machine. I
>   know how I would build a restricted execution environment for such
>   markets. However, Java is 1) too slow, since if you are selling rendering
>   cycles or such you don't want to be running an interpreter, 2)
>   insufficently safe, and 3) paradoxically, insufficiently powerful for the
>   sort of code you would want to run in such an environment. 
> 
> What solution is fast enough and safe enough and powerful enough?  Does
> such a solution exist?  I say, No, it doesn't.

I say yes, it does.

If what you want to do is run a distributed ray tracer, and sell the
cycles for it, you can run an ordinary executable on a machine with an
unusual kernel. If, for example, you could completely revoke access to
the bulk of system calls and only permit I/O to a small number of
inherited file descriptors, you could probably manage to get a
reasonable engineering solution in place that would be suitable solely
for things like markets in CPU cycles. I could probably design such an
execution environment in a few weeks. Such an execution environment
radically differs from Java in so far as it has a "what is not
expressly permitted is forbidden" strategy all the way down to the
kernel interface. It might still be dangerous in the presence of
things like kernel bugs that permit you to write arbitrary memory
addresses, however. My suspicion is that something thats okay from an
engineering standpoint should be possible.

> But let's not have a food fight.  Although entertaining in the short term,
> food fights are actually deathly boring and incredibly unfruitful in the
> long term.  I'm interested in helping people do interesting things in a
> reasonably secure way, on the internet, using Java.

What you are saying, Marianne, is that you work for the Java group at
Sun, Java has become very important to Sun's strategy, and that thus
Java isn't going to be abandoned regardless of techincal problems.

> We're working on a response to the Felten el al. paper, which will
> be posted to the net shortly.  I think some of their points are
> perfectly valid, some of their points are irrelevant, and a lot of
> the presentation is melodramatic.  Melodrama is good for sound
> bites, I guess.

Look, not to be insulting, but your job pretty much dictates that you
have no choice but to declare their work to be incorrect. I mean, your
customers would be very mad for you to say otherwise, and your
management would fire you if you didn't say otherwise. This must
certainly color your commentary. Understand, I'm not accusing you of
being a bad person, but I am noting that you aren't in a position to
be objective.

Perry

I guess you're opting for food fight? 

I'll let people who know me judge if they think I'm mouthing party line
or what not ..

:-) 

Marianne

Marianne Mueller writes:
> I guess you're opting for food fight? 
> 
> I'll let people who know me judge if they think I'm mouthing party line
> or what not ..

As I said, I don't think you are a bad person. I merely think that no
one could expect the Java security person to say anything other than
what you have said.

.pm

>From the begining of the Java discussion on this list, Perry has been
predicting that a continuous series of security holes would be discovered
in Java implementations.

So far he's been proven right.

I like Java -- I'm not a professional programmer, and Java is a lot easier
for me to work with than C++.  And I can buy the argument that for many
people the benefits of applets will outweigh the security risks.  I'm 
willing to run sendmail, and I'm willing to run Java as well.  I'm not 
working in a finance house, and there's not anything that sensitive on my 
machine.

It also seems likely to me that Java secure mail applets and remailer
clients will do a lot of good from a cypherpunk point of view.  Java looks
like it's going to put easy to use gui crypto tools within reach of
everyone with a web browser.

So I'd like to see Java catch on, as long as users are allowed to make 
informed decisions about the risks and the benefits of running applets.

But Perry has a track record on this issue (and on many other issues as
well).  I don't think many people here are going dismiss what he's saying
because someone called him a food fighter.

Alex Strasheim <cp@proust.suba.com> writes:

 > I like Java -- I'm not a professional programmer, and Java
 > is a lot easier for me to work with than C++.  And I can buy
 > the argument that for many people the benefits of applets
 > will outweigh the security risks.

I hope everyone here realizes that Java is not just about
Applets. Applets are simply one of many abstract classes in Java,
suitable for further refinement into things that get plugged into
Web pages.

Java itself is a full-blown programming language, like C or C++,
with command line processing conventions, runtime libraries, and
all the other amenities of procedure-oriented programming
languages.  You can write anything you want in Java, and execute
the program at a shell prompt by simply typing its name followed
by some arguments.  (Perhaps you might have to alias "name" to
"java name", but you get the general idea)

While the security issues being discussed are indeed important
for Applets, where untrusted code from God-knows-where comes into
intimate contact with the program visible decor of ones platform,
they are less important when Java is used as an ordinary
programming language, in order to take advantage of its
platform-independence and incorruptable run-time structure.

Again, this is not directed at Alex or anyone else specifically,
but some of the messages I have read here recently have given the
distinct impression that people are thinking of Java as a
language solely for writing Applets, as opposed to something more
general and a bullet-proof replacement for C++ and C.

I think we'll be seeing a lot of things written in Java in the
future.  A good first start would be a set of Daemons for Unix
which run on any platform and are totally immune to the
buffer-overrun type holes which permit people to easily break
into systems.

--
     Mike Duvos         $    PGP 2.6 Public Key available     $
     mpd@netcom.com     $    via Finger.                      $

On Sat, 27 Apr 1996, Marianne Mueller wrote:

> But let's not have a food fight.  Although entertaining in the short term,

I don't owe you anything! I don't owe you anything! Oh, food fight.

> reasonably secure way, on the internet, using Java.  We're working on a
> response to the Felten el al. paper, which will be posted to the net
> shortly.  I think some of their points are perfectly valid, some of their
> points are irrelevant, and a lot of the presentation is melodramatic. 

Most of the emphasis in the paper seems to be on the lack of a 
denotational semantics for java and the java VM, and on the lack of a 
formally defined set of rules for type inferencing rules. 

For security purposes, java-the-language is not particularly important; 
it's the VM code that counts. This is a shame, as it's pretty easy to 
come up with a reasonably clean denotation for java, wheras the byte code 
gets pretty messy. It would probably be easier to get a cleaner semantics 
if you define a set of rules to transform the byte code into an alternate 
form and then define the denotational semantics for that. The paper 
mentions  that the authors believe the VM to be unsuitable for a 
denotational semantics, but the issue is not explored to any great depth. 

> Melodrama is good for sound bites, I guess. 

I take it twenty minutes before I go to sleep; seems to work pretty well.


---
They say in  online country             So which side are you on boys
There is no middle way                  Which side are you on
You'll either be a Usenet man           Which side are you on boys
Or a thug for the CDA                   Which side are you on?
  National Union of Computer Operatives; Hackers, local 37   APL-CPIO

"Perry E. Metzger" writes:
>You can do that safely without making it dangerous for your machine. I
>know how I would build a restricted execution environment for such
>markets. However, Java is 1) too slow, since if you are selling
>rendering cycles or such you don't want to be running an interpreter,
>2) insufficently safe, and 3) paradoxically, insufficiently powerful
>for the sort of code you would want to run in such an environment.

The speed can be significantly addressed by compiling the byte-code to
local machine instructions, but given the sheer number of junk cycles
that are made available by letting a Java interpreter sell them, it
doesn't much matter for some applications.

I agree that Java is currently too unsafe.  The current Java model may
not even be salvageable (that being where I got in on this thread).
It's the concept embodied by Java (and it's many conceptual cousins,
Scheme, Safe-TCL, E, etc.) that I was talking about.

I don't understand what you mean by "insufficiently powerful".  It's as
expressively powerful as most high-level languages, and computationally
Turing equivalent.  It's lack of power seems entirely in the performance
arena, which may be solved, eventually.

Scott Brickner writes:
> I don't understand what you mean by "insufficiently powerful".  It's as
> expressively powerful as most high-level languages, and computationally
> Turing equivalent.  It's lack of power seems entirely in the performance
> arena, which may be solved, eventually.

Java applications can't save files to disk or use data files on
disk. If you were, for instance, buying two CPU weeks of idle time on
some machines, you would need stuff like checkpointing or the ability
to save intermediate results.

Perry

> 
> Java applications can't save files to disk or use data files on
> disk.

	Uh, yes they can. It's the applets that can't.

-- 
Sameer Parekh					Voice:   510-601-9777x3
Community ConneXion, Inc.			FAX:     510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.net/ (or login as "guest")		sameer@c2.net

sameer@c2.org writes:
> > Java applications can't save files to disk or use data files on
> > disk.
> 
> 	Uh, yes they can. It's the applets that can't.

Same difference -- we were talking about applets (or at least "safe
java" to coin a phrase) as a way of selling compute cycles.

.pm

On Mon, 29 Apr 1996, Perry E. Metzger wrote:

> 
> Java applications can't save files to disk or use data files on
> disk. If you were, for instance, buying two CPU weeks of idle time on
> some machines, you would need stuff like checkpointing or the ability
> to save intermediate results.

See the documentation for FileOutputStream; unsigned java applets can't 
make persistent changes, but signed ones can. Applications can always 
access the file system

Simon

---
They say in  online country             So which side are you on boys
There is no middle way                  Which side are you on
You'll either be a Usenet man           Which side are you on boys
Or a thug for the CDA                   Which side are you on?
  National Union of Computer Operatives; Hackers, local 37   APL-CPIO

"Perry E. Metzger" writes:
>Scott Brickner writes:
>> I don't understand what you mean by "insufficiently powerful".  It's as
>> expressively powerful as most high-level languages, and computationally
>> Turing equivalent.  It's lack of power seems entirely in the performance
>> arena, which may be solved, eventually.
>
>Java applications can't save files to disk or use data files on
>disk. If you were, for instance, buying two CPU weeks of idle time on
>some machines, you would need stuff like checkpointing or the ability
>to save intermediate results.

It is false that Java applications "can't" save files to disk.  Java
has no I/O facilities, exactly like C and C++ have none.  Any I/O
capability must be provided in external functions.  The applet
environment doesn't include file I/O functions, but it can be easily
added in a reasonably safe way (filesystem object only allocates a fixed
region of real disk space, applets are charged to use it, after the
"rent" is gone, the blocks are freed, etc.)

Java applications may also send checkpoint data or intermediate results
back "home", even in the current environment.

sameer@c2.org writes:
> > I go further. Java, as envisioned, cannot be made secure. It is too
> > powerful a language. Furthermore, it is unnecessary for the tasks that
> > it is used for, which are basically adding fancy wacky graphics and
> > simple applications and such to web pages.
> 
> 	Even though that is all it is used for now, I think it was
> *intended* to be used for more.

So much the worse.

I don't think its a good idea to download random programs and run them
without even realizing it, especially when they run in an execution
environment which is not particularly emasculated. I don't think this
can be made particularly secure in the general case. It is a bad
paradigm. I've said it before, and everything we've seen thus far
about Java supports my contention.

Perry

On Fri, 26 Apr 1996 sameer@c2.org wrote:

> > 
> > I go further. Java, as envisioned, cannot be made secure. It is too
> > powerful a language. Furthermore, it is unnecessary for the tasks that
> 
> 	Even though that is all it is used for now, I think it was
> *intended* to be used for more.

At Usenix 96 in San Diego it was pointed out that applets are an abberation.
This is a complete language designed to displace C++, Visual Basic and
other OO languages.  Thinking of Java as simpy a Web enhancement tool
is short sighted.

Personally it is more attractive than C++ for product development and
we are trying to get it on FreeBSD, SCO UnixWare and SCO OSR5.  Using 
Java for applets _only_ is like fucking your mother... Most of us are
not into it.

Dan
-- 
 Dan Busarow
 DPC Systems
 Dana Point, California

>>>>> "Dan" == Dan Busarow <dan@dpcsys.com> writes:

    Dan> At Usenix 96 in San Diego it was pointed out that applets are
    Dan> an abberation. This is a complete language designed to
    Dan> displace C++, Visual Basic and other OO languages. Thinking
    Dan> of Java as simpy a Web enhancement tool is short sighted.

    Dan> Personally it is more attractive than C++ for product
    Dan> development and we are trying to get it on FreeBSD, SCO
    Dan> UnixWare and SCO OSR5. Using Java for applets _only_ is like
    Dan> @#$% your mother... Most of us are not into it.

I have been doing work in Java for the past half a year or so (most
recent project: implementing SSL 3.0). I can't say I don't like it at
all, but I like C++ much more. Here are my thoughts about the issue.
Since there is a subjective component to choosing a programming
language, flamewars are very likely to erupt when you say "Language A
is much better than Language B", but it may still be interesting to
read others' opinions.

As I see it, Java as a language is basically (C++) + (garbage
collection) - (templates) - (operator overloading) - (multiple
inheritance) - ... Garbage collection is a very useful thing in many
cases (though in some it may be a great slowdown), but there is no
real reason not to incorporate GC into a C++ implementation, or at
least give the user an option of doing it.

On the other hand, templates are an extremely useful feature, since
they allow huge amounts of code reuse (Wei Dai's crypto++ library is
a great example of the use of templates). They also enable a C++
programmer to do such things as run-time array boundary checking
(refuting one of the traditional arguments about the dangers of C++),
or a type which is a subrange of another. Java programs can have some
template-like functionality through the use of the Object class, but
that is very limited. For instance, compare the following hypothetical
Java code

	List l;
	l.append(new Integer(1));
	l.append(new Integer(2));
	int x = ((Integer)(l.head())).intValue();

with this C++

	List<int> l;
	l.append(1);
	l.append(2);
	int x = l.head();

The second version is clearly more readable. It would also be more
efficient since no run-time conversions would be done.

There are also situations in which templates would work, but Objects
would not. For instance, it is very easy in C++ to make a template
class Range<type, min, max> that would be a subrange [min, max] of
type, and would do run-time checks for any assignments. There is no
way you can do this in Java.

Java also lacks operator overloading. 'V = M*W + A' (where V, W, and A
are vectors, and M is a matrix) is much easier to read than 'V =
Vector.add(Matrix.multiply(M, W), A)'. The same would apply to a big
integer class. 

The lack of multiple inheritance is somewhat alleviated with the use
of interfaces, but there are cases where this is not enough. The
crypto++ library uses a lot of nontrivial multiple inheritance.

Another strange deficiency of Java is that there is only one way to
pass parameters. All class parameters are passed by reference, while
all primitive-type parameters are passed by value. What if you need to
pass an integer by reference? Also, when you pass a class parameter,
the method can modify it arbitrarily, since Java does not allow
constant variables.

As for the usual complaint "C++ has pointers which are unsafe!!!", the
following can be said. First, Java has pointers too: all class objects
are actually pointers to data, so, for instance, "A = B" in Java would
mean "Make A a pointer to the same location as B", not the traditional
meaning "Make A a copy of B". Second, when it is said that C++
pointers are unsafe, usually two things are meant: C++ allows you to
cast a pointer of one type to a pointer of another type, and C++
allows for pointer arithmetic. Both of these features are not needed
in virtually all programs (they were probably retained only for C
compatibility), except those that interface with the low-level system
calls. Also, both of them can only be invoked explicitly. Thus, the
programmer which uses them has only himself to blame if anything goes
wrong.

In summary, I don't see Java as the new great language that is going
to replace C++ in the standalone application arena, even if Java ran
as fast as C++. It is true that Java has a nice standard library
(including threads), but there is no reason whatsoever why a library
with a very similar interface could not be written in C++.

On the other hand, considering Java as a language specifically for
applets is a completely different matter. Here it does not compete
with C++. The competitors -- Safe-Perl, Python, and Safe-TCL (and
perhaps some Scheme-like languages) -- don't stand a chance without
being supported by Netscape.

Thus I would say that Java became so popular for the following
reasons:

- It was developed by Sun.
- It was licensed by Netscape.
- It is C++ -like.
- JDK (and its source) were made freely available.

Constructive comments and discussion of this issue would be
appreciated, but send the flames to /dev/null.

Sincerely,
Victor Boyko

-- 
Victor Boyko <vboykod@is-2.nyu.edu>
http://galt.cs.nyu.edu/students/vb1890/
To get my PGP key, finger or send e-mail with subject "send pgp key".

On Fri, 3 May 1996, Victor Boyko wrote:

> I have been doing work in Java for the past half a year or so (most
> recent project: implementing SSL 3.0). I can't say I don't like it at
> all, but I like C++ much more. Here are my thoughts about the issue.
> Since there is a subjective component to choosing a programming
> language, flamewars are very likely to erupt when you say "Language A
> is much better than Language B", but it may still be interesting to
> read others' opinions.

I agree completely with Victor's analysis.  I usually try to avoid me-too
posts, but I've been meaning to write an explanation of why I haven't
started using Java and am not planning to port my Crypto++ library to
Java, so this saves me the effort.

Wei Dai