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.
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
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.
[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
participants (8)
-
frantz＠netcom.com -
nelson＠crynwr.com -
Perry E. Metzger -
Raph Levien -
s1113645＠tesla.cc.uottawa.ca -
Simon Spero -
Vladimir Z. Nuri -
Wei Dai