On Mon, 6 Nov 1995, Ray Cromwell wrote:

...

WARNING - THIS MESSAGE CONTAINS INFORMATION THAT MIGHT BE CONSIDERED AS A FLAME BY SOME READERS - IT IS LONG AND TEDIOUS - YOU ARE WARNED!

...

From the Java Web pages (as combined in Firewalls/BoS):

...

The language's security features (not just applets):

[Long list of bullshit deleted]

I don't think that this is *bullshit* ... the questions I mean ... but, I for one am tired of people promoting products in a manner which flies in direct contravention of expert consensus. No one would accept a pharmaceutical company that says a product is X, if it is in fact Y. And no one would question if a researcher came forward, and corrected the company and set the record straight. This is generally called ETHICS ... not bullshit. The problem is not in the messenger, it's in the organization that is simply willing to roll the dice when it comes to public safety and security.

"Dr" Cohen. If you want to criticize Java, why not read the technical papers rather than spewing questions and assertions based from ignorance.

I've got a better suggestion. Why don't companies like Sun ensure that their sales and technical material is reviewed for gross inaccuracies and/or misrepresentations?

When you want to criticize a piece of engineering, you don't look at the feature list or white paper. As is made clear in your post, you don't know the meanings of phrases used in the Java paper, nor do you understand how the machinery works. (e.g. byte code verifier)

I won't speak for Dr. Frederick B. Cohen, but I will speak for myself, and provide this list with but a single example. And I won't quote from a white paper, but will instead quote from some Sun literature which crossed my desk the day before yesterday, literature that Sun provided as part of their worldwide introduction of Ultra workstations. What they called a "breakthrough for network computing". What follows is not "technical commentary", but is simply what they provide as information to MIS managers, Sun resellers and invited press. This copyrighted brochure, which looks like it was printed 11/95 makes the following verbatim comment on the "Java Internet Application Language".

Java has an extensive library of routines for coping with TCP/IP protocols such as HTTP and FTP. Java applications can open and access objects across the net via URLs with the same ease that programmers are used to when accessing a local file system.

Java is intended to be used in networked/distributed environments. Therefore, much emphasis has been placed on security. The product enables programmers to create virus-free, tamper-free systems through public-key encryption authentication techniques.

Hmmm, maybe I'm confused, but this is grossly overselling a product's capabilities, and is setting absolutely unrealistic expectations -- expectations which are doomed from the start never to be met, let alone exceeded. This expectations/satisfaction gap will ultimately lead to customer dis-satisfaction. Then again ... the solution to virus-free, tamper-free systems with TCP/IP protocol "coping" has always been a problem that's been waiting for a "product solution" to help all of us to enable our programmers. God help us all. As part of my copious spare time, I might make a personal comment which hopefully gets to some of the powers that be at Sun. Firstly, I wasn't aware that HTTP was a TCP/IP protocol. I didn't even think that there was a draft RFC on it. I thought that all that there was, was an internet-draft, which is a different kettle of fish. I never realized that HTTP was on standards track, and part of the appliction protocol. It really is news to me. But that's a quibble, and I'm really behind on my reading, so, I could be wrong. My second comment is perhaps more actionable. I would much rather that a product clearly and definitively state what it has implemented. Maybe something like the following. Implementation of the following IETF (Internet Engineering Task Force) protocols :IP (RFCs 791, 894; MIL-STD 1777); UDP (RFC 768); TCP (RFC 793, MIL-STD 1778); ARP (RFC 826); RARP (RFC 903); ICMP (RFC 792); BootP (RFCs 951, 1048); RIP (IDEA004); DNS (RFCs 1034, 1035); Internet Subnetting (RFC 950); and Internet Assigned Numbers (RFC 1010). Maybe, also that the product complies with Requirements for Internet Hosts Communications Layers (RFC 1122) and with A Standard for the Transmission of IP Datagrams over IEEE 802 Networks (RFC 10.. something or other). This is far more informative (ironically) than saying that:

Java has an extensive library of routines for coping with TCP/IP protocols such as HTTP and FTP.

Hmmm, FTP. That's RFC 7?? or something like that, isn't it?? As an example, I'd like to know how Java handles a file, that is called foo.bar.au. Does a .au file refer to an audio file, or does it refer to something from Australia?? I'll stop here, and not continue with my deconstruction, especially the part that continues:

Java is intended to be used in networked/distributed environments. Therefore, much emphasis has been placed on security. The product enables programmers to create virus-free, tamper-free systems through public-key encryption authentication techniques.

To every problem, a product solution ... we can leave mathematician's at the door, and simply enable our programmers. Those technical analyst rocket scientist types, really can't know anything, at all. Can they? Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E. P.P.S. To Sun: I was also a bit disappointed that nobody thought to show what a vice-presidential tribble looks like on satellite simulcast ... then again, I was thrilled with the female "trader" who spoke about patterns in chaotic systems to her cab driver. Did she work the back office at Daiwa, or something?? Probably believe's in runs of luck, too ...