Re: Java

At 10:22 PM 6/3/96 -0400, Perry E. Metzger wrote:
>I've been rather hard on Java here lately.

I'll say.  You have also ignored some of Java's other features.  Machine
independence is probably the most important.  A nice, small, easy to learn
language is another.

[As an aside, when I attempted to compile Wai Dei's crypto lib 2.0 with the
Symantec Project Manager C++ compilers, none of the 3 would compile it. 
The one which generated the fewest errors had "internal error" on two
modules.  This problem occurs because C++ is such a large language, with a
number of obscure features which compiler writers don't always handle.  In
addition, C++ is in no way machine independent.  The simplest example is
that sizeof(int) is machine dependent.]
>
>...
>
>Sun is, unfortunately, suffering from a substantial hubris problem. As
>I have noted, the original Java applet security model and all the
>followups have had exactly the same problem -- they depend on perfect
>implementation of every element of the security model for the security
>to work, instead of having the realistic and conservative assumption
>that portions of the model will be misimplemented, and designing for
>defense in depth.

If you want defense in depth, run your Java interpreter in an OS
environment which limits the interpreter's access to only those resources
you wish it to access.

I get the impression that the environment you are concerned with is a bunch
of PCs running W95 or NT.  These OSs are fragile enough, particularly to
the denial of service attacks your users can not tolerate, that the only
way to approach safety is to only run software which has been approved by
an in-house testing authority.  Even with the in-house testing authority,
you really need a better OS to protect against testing failures.


>Beyond that, however, they have created the ultimate hype
>monster. Java is a neat idea looking for a good application. I use the
>web all day long and I have yet to see a good use for Java.

There have been discussions of crypto applications in Java.  Doing the
crypto on the user's system before sending data thru the net is a useful
application.  While, as a number of us have pointed out, there are problems
doing crypto with Java, it may be the easiest way to deliver strong crypto
quickly to Joe Websurfer.

In the long run, I hope to use Java to sell cycles.  Java has the advantage
in a cycle market that it is machine independent, and the Just In Time
compilers should make the performance reasonable.

Regards - Bill


------------------------------------------------------------------------
Bill Frantz       | The CDA means  | Periwinkle  --  Computer Consulting
(408)356-8506     | lost jobs and  | 16345 Englewood Ave.
frantz@netcom.com | dead teenagers | Los Gatos, CA 95032, USA

Bill Frantz writes:
> At 10:22 PM 6/3/96 -0400, Perry E. Metzger wrote:
> >I've been rather hard on Java here lately.
> 
> I'll say.  You have also ignored some of Java's other features.  Machine
> independence is probably the most important.

Many languages are machine independent. Thats hardly a new feature.

> A nice, small, easy to learn language is another.

Scheme, anyone?

However, your point is taken. Java is a neat little language in many
ways. However, that isn't cause enough for literally fifty books on
the subject to be on display, including breathless ones proclaiming
"Tips from experienced Java programmers!" as if there are any in the
world at this point. There are dozens of cute little languages in the
world -- scheme, smalltalk, etc, etc.

I mean, with all the "Teach yourself Java in 21 days" and company
books coming out, you would think you were dealing witht he major
application programming language for the world instead of something
that at the moment is used for almost nothing more interesting than
fake scrolling LED sign applets.

> If you want defense in depth, run your Java interpreter in an OS
> environment which limits the interpreter's access to only those resources
> you wish it to access.

Since that doesn't exist, it isn't an option for my users. It is not,
in any case, my obligation to make Java secure. I'm not the one hyping
it.

> >Beyond that, however, they have created the ultimate hype
> >monster. Java is a neat idea looking for a good application. I use the
> >web all day long and I have yet to see a good use for Java.
> 
> There have been discussions of crypto applications in Java.

Useless, almost, for a web environment.

If you want to really put Crypto in netscape, the plugin facilities
and a good C compiler are a better tool, and C is 99% portable.

> While, as a number of us have pointed out, there are problems
> doing crypto with Java, it may be the easiest way to deliver strong crypto
> quickly to Joe Websurfer.

You could hand any websurfer a Netscape PGP plugin without much work
at all, and you could easily build it on lots of platforms. After all,
look at how many platforms that lowly C code like PGP runs on.

Perry

Vladimir Z. Nuri wrote:
[...]

> you don't get it, as others have pointed out repeatedly. you conveniently
> ignore Frantz' points about the well-known difficulties of porting C. there
> is a big difference in what is conneted by the word "portable".
> if it take a zillion different makefile rules to create the "same"
> program on different machines, is that "portable"? isn't that
> defeating the purpose somewhat? c is "sort of" portable. it is
> "in theory" portable. Java is portable "in theory and practice".

   This point is simply not true, at least for Java as it exists in 
Spring 1996. Almost every Java applet I've seen has little UI glitches 
that prevent it from displaying and operating correctly on all 
platforms. Further, there are little glitches in the language 
implementation and library design that often cause portability problems. 
For example, the first cut of Hal's PGP applet had the standard UI 
problems, plus the fact that a "spinner" thread caused the entire 
browser to lock up -- on Unix, but not on Windows. And this was a 5000 
line of code applet. Hal was able to fix the problems, but it's easy to 
see how the effort involved in this "portability engineering" could 
become comparable to your thousand-line makefile as applications scale 
up.
   The promise is there, but Java has not yet delivered.

   Another concern with Java is that it acheives portability at the cost 
of enforcing a lowest common denominator. For example, all real Windows 
applications support OLE, and all real Mac applications support Apple 
Events. Java applets, and even applications, can't do either. To me, 
that makes the accomplishment of portability a bit less impressive, even 
if it were so.

Raph

>
>>  c is "sort of" portable. it is
>> "in theory" portable. Java is portable "in theory and practice".
>
>   This point is simply not true, at least for Java as it exists in 
>Spring 1996. Almost every Java applet I've seen has little UI glitches 
>that prevent it from displaying and operating correctly on all 
>platforms.

you caveat, as you write it, is very significant. what I wrote about
was that the burden of portability is placed on the PROGRAMMER for
C. the burden of portability is placed on the Java language implementers
for Java. a BIG difference. Java may be *riddled* with bugs at the moment.
but who is responsible for fixing them? every single programmer in 
existence who wants to port code? (that is what effectively happens
with C makefiles) or the language designers? i.e. Java Inc.?  you
can see the tremendous difference here. the level of portability
*demanded* by the language specification of Java is far higher than
C. whether this works out in practice will take years of fine tuning.
but look how old C is-- 20 years-- and has its portability gotten
better with time, or worse? give Java another few years and its going
to be so good that no one will be arguing with supporters.

 Further, there are little glitches in the language 
>implementation and library design that often cause portability problems. 
>For example, the first cut of Hal's PGP applet had the standard UI 
>problems, plus the fact that a "spinner" thread caused the entire 
>browser to lock up -- on Unix, but not on Windows. 

whose problem is this? his or Java implementors? not his. granted,
in practice he may have to design around it. but Java is in its infancy
and you can't demand mature characteristics. as I emphasized, it
is evolving. it is a step in the right direction. you can't ask Excel
to be written before the PC has been invented. similarly, Java will
not crystallize for some time yet. (however UI problems do seem to me
to be the source of the greatest amount of intrinsic compatibility
problems. I was not wholly impressed with the labor that seemed to
go into the Java UI at first-- it seemed like a little of an afterthought)

And this was a 5000 
>line of code applet. Hal was able to fix the problems, but it's easy to 
>see how the effort involved in this "portability engineering" could 
>become comparable to your thousand-line makefile as applications scale 
>up.
>   The promise is there, but Java has not yet delivered.

I agree that in practice Java is pretty weak at the moment. but consider
how much money Sun has made from it. do you realize they poured 5M
initial development costs into it? can you be sure they will recoup
that? they probably have, but they've been incredibly generous. I am
never ceased to be amazed at how much people rant at stuff that is
given away for free or amazingly low cost.

>   Another concern with Java is that it acheives portability at the cost 
>of enforcing a lowest common denominator. For example, all real Windows 
>applications support OLE, and all real Mac applications support Apple 
>Events. Java applets, and even applications, can't do either. To me, 
>that makes the accomplishment of portability a bit less impressive, even 
>if it were so.

Java cannot solve every programming problem on the planet. it cannot
be a secure OS. it cannot give you a worldwide object standard. Java
has an event mechanism just as Apple does, and it supports object
oriented programming just as OLE is a standard associated with OO.
IMHO it did what it did well. if you want OLE go to microsoft, if
you want Apple Events program on the apple!!! if you want one language
in which you don't have to worry about every standard in the world,
try Java.

Raph Levien writes:

 >    Another concern with Java is that it acheives portability at the cost 
 > of enforcing a lowest common denominator. For example, all real Windows 
 > applications support OLE, and all real Mac applications support Apple 
 > Events. Java applets, and even applications, can't do either. To me, 
 > that makes the accomplishment of portability a bit less impressive, even 
 > if it were so.

On the other hand, you have the potential for running a second Java
applet inside a first Java applet, achieving OLE in a portable
fashion, across all operating systems.  Encryption everywhere.

-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | PGP ok
11 Grant St.      | +1 315 268 1925 voice | It's no mistake to err on
Potsdam, NY 13676 | +1 315 268 9201 FAX   | the side of freedom.

maybe Java is about a generation gap in programming languages...??

>Bill Frantz writes:
>> At 10:22 PM 6/3/96 -0400, Perry E. Metzger wrote:
>> >I've been rather hard on Java here lately.
>> 
>> I'll say.  You have also ignored some of Java's other features.  Machine
>> independence is probably the most important.
>
>Many languages are machine independent. Thats hardly a new feature.

you don't get it, as others have pointed out repeatedly. you conveniently
ignore Frantz' points about the well-known difficulties of porting C. there
is a big difference in what is conneted by the word "portable". 
if it take a zillion different makefile rules to create the "same"
program on different machines, is that "portable"? isn't that
defeating the purpose somewhat? c is "sort of" portable. it is
"in theory" portable. Java is portable "in theory and practice".

>However, your point is taken. Java is a neat little language in many
>ways. However, that isn't cause enough for literally fifty books on
>the subject to be on display, including breathless ones proclaiming
>"Tips from experienced Java programmers!" as if there are any in the
>world at this point. There are dozens of cute little languages in the
>world -- scheme, smalltalk, etc, etc.

a little clue to you Perry, there are so many Java books because there
is such a huge market for them. I always thought you were an 
anarchocapitalist and in favor of "letting the market decide". in a
sense you are arguing with the market, it seems, in much the same
way a liberal might say, "why are all you greedy businessmen hyping
your railroads so much?!?!?"  however I fully grant you that Java has been
the most hyped computer language on the planet. (but then again, I
didn't hear you whining when Intel started their "intel inside" 
campaign). I think what you are seeing is that people are excited
by the possibilities. the public has grasped the message behind Java,
which at this point is more about potentialities. its like saying,
"who is the next marc andreesson?" 

the problem appears to be simply that you are annoyed that other people are
excited about java, and you seem not to like excitement. you don't
like hype. well, personally, I think the hype is pretty damn amusing.
the world couldn't have given the slightest damn about geek computer
programmers say 5 years ago, but after the internet and Netscape, Yahoo,
and Java it's suddenly incredibly trendy. I think its quite enjoyable.
I suppose if I was over 40 and worked in a conservative wall street firm,
I'd have a totally different view. maybe Java is all about a generation
gap in computing. hey!! the first language that the "older generation"
hates. sounds like a good reason to go after it, sort of like rock-n-roll
and Woodstock suddenly being aged and uncool.

>I mean, with all the "Teach yourself Java in 21 days" and company
>books coming out, you would think you were dealing witht he major
>application programming language for the world instead of something
>that at the moment is used for almost nothing more interesting than
>fake scrolling LED sign applets.

actually, the quality is not all that great in all of them, I agree. 
I thought for example Van Der Linden's "Just Java" is a pretty weak one. 
it has paper airplane instructions in parts of it. but hey, maybe
again its a generation gap thing. I bet I would have really enjoyed
the book and thought it "way cool" in my teens. <g>

>Since that doesn't exist, it isn't an option for my users. It is not,
>in any case, my obligation to make Java secure. I'm not the one hyping
>it.

no, but you are the one ranting at it. why? it is not Java's 
obligation to make OSes more secure either!!! @#$%^&*


>You could hand any websurfer a Netscape PGP plugin without much work
>at all, and you could easily build it on lots of platforms. After all,
>look at how many platforms that lowly C code like PGP runs on.

look at the complicated PGP makefiles. count how many MAN MONTHS of additional
testing and work is required merely to deal with the makefiles. count
how many BUGS are due to improper compilations. count how hard it
is to track this kind of thing. count how hard it is to test your
makefiles not given that you have all the zillion different environments
you are supporting immediately available for testing.

every language is about tradeoffs. if you continue to say that C
is better than Java for just about anything, then you clearly are
not saying anything very relevant based on most people's opinions.

why am I arguing with you on this? because while you are usually
a pretty sensible person, you are really way off
base on this one. the world requires a mix of conservatism and
imagination. you've got the conservatism down totally, but the
imagination part you are lacking, and hence your criticism of
java. PM, imagine yourself at the invention of the LAN, or the PC,
or the C language. what would you have said to the designers? 
"you are all boneheads!! what you are doing can't be done!! you
are wasting your time!!"  do you think perhaps that every useful
computing tool that can be invented has already been invented?
hee, hee.

"Vladimir Z. Nuri" writes:
> >Many languages are machine independent. Thats hardly a new feature.
> 
> you don't get it, as others have pointed out repeatedly. you conveniently
> ignore Frantz' points about the well-known difficulties of porting
> C.

Who said anything about C, Detweiler. Smalltalk. Scheme. Postscript. 
There are dozens of them out there. All of them are totally machine
independent. You could run Smalltalk images byte for byte identical on
large numbers of different processors years and years and years
ago. Byte codes aren't new either -- Smalltalk's virtual machine, PSL
and others had them decades ago.

The rest of your comments are equally silly.

Perry

On Tue, 4 Jun 1996, Perry E. Metzger wrote:

> Who said anything about C, Detweiler. Smalltalk. Scheme. Postscript. 
> There are dozens of them out there. All of them are totally machine
> independent. You could run Smalltalk images byte for byte identical on
> large numbers of different processors years and years and years
> ago. Byte codes aren't new either -- Smalltalk's virtual machine, PSL
> and others had them decades ago.

One thing that might distinguish Smalltalk's comparative market faliure from 
Java's apparent market success, apart from the hype, is the lack of a 
free implementation for windows or even an easy to use free version for 
dos (both of the dos ones I tried failed to work for some reason).

A good free class lib for net programming and GUI programming would have
helped too (something more substantial than the windowing primitives it
comes with). Java has all these things. (One thing that detractors of
Smalltalk claim is that it is slow--slower than Java. However there is a
research dialect from Sun called Self which is supposed to be 50% as fast
as C.)

Also if one looks on the commercial side of things, developper versions
(which are wonderful) are much more expensive than the equivalent visual
basic (having purchased and tried a cheaper smalltalk for a course, I
would have far preferred staying with it rather than c++ or VB. Hopefully
Java does what it couldn't. However it is never too late, there is always
market for very easy to learn and program OO languages that aren't c++.
If you care so much Perry, you could always give it a try.)

On Mon, 17 Jun 1996 s1113645@tesla.cc.uottawa.ca wrote:
> 
> helped too (something more substantial than the windowing primitives it
> comes with). Java has all these things. (One thing that detractors of
> Smalltalk claim is that it is slow--slower than Java. However there is a
> research dialect from Sun called Self which is supposed to be 50% as fast
> as C.)

Smalltalk was in fact the first object oriented language to ever be
tweaked enough to be useful (smalltalk-80 is where JIT came from). 

Self is a completely different kettle of ball-games; it's older than java,
and based on a totally different conception of OOP. The only major 
language Ican think of that's from the same family is newton script. Self
does away with the concept of classes, and instead uses prototypes to
inherit from. The main design principle seems to have been: create a
language that's as slow as possible, then see how well you can optimise it
:)

Simon

> [As an aside, when I attempted to compile Wai Dei's crypto lib 2.0 with the
> Symantec Project Manager C++ compilers, none of the 3 would compile it. 
> The one which generated the fewest errors had "internal error" on two
> modules.  This problem occurs because C++ is such a large language, with a
> number of obscure features which compiler writers don't always handle.  In
> addition, C++ is in no way machine independent.  The simplest example is
> that sizeof(int) is machine dependent.]

It's true that C++ is large and has many features, some obscure.  But the
fact is most of those features are actually very useful.  I suspect many
experienced C++ programmers do not like Java even though Java looks a lot
like C++ because they are so used to having those features in C++.  Take a
look at Victor's earlier post on this subject.

Portability is certainly one of the big problems of C++.  But it can be
done and should become easier in the future as the compilers standarize. 
If anyone has trouble compiling Crypto++, please send me a report so I can
help you figure out workarounds.  Also, send bug reports to the compiler
company if you think there are bugs in the compiler.

Wei Dai