Re: Java

[Ray Cromwell <rjc@clark.net>]

  Well those concerns are all fine and swell, but the same kind
of reasoning applies to any network application. There are buffer overflow
bugs in almost every web browser, there are overflow bugs in CERN HTTPD3.0,
and who knows, there are probably bugs in ELM/PINE. Millions of people
download software from the internet without seeing the source code
everyday and risk getting hit by trojan horses and viruses. People
make all kinds of transactions everyday where they rely on nothing more
than trust. (and a future tit-for-tat legal suit if possible) I am of
the opinion that risk is good. Java will not be perfect. There will
be holes, I'm sure of it. And each generation of web languages will be
more efficient and more secure, but none will ever be perfect. It's all
part of evolution. It's a problem that will be researched and
improved on, but you've got to break some eggs to make a cake
somewhere. 

  And the situation without Java is not much better. Most of Java 
functionality is faked with CGI scripts, usually written in perl,
and there are plenty of ways to screw up a CGI implementation to allow
holes.

  As I mentioned before, Java file i/o is not built into the language.
It is provided through a Java class you can use that implements native C code
methods. This is where the write restrictions are handled. All that is
needed to remove the ability to do file i/o is to delete this class
from your installation. It's like having C, but no standard library.

  Java is mostly a risk to consumers (the users with the browsers), and
not corporate networks who are running servers, *unless* the employees
are using Java on the firewalled network. 

  Java is a lot better than the situation with microsoft network, whereby
a user can send you a 386 executable, and it shows up with an icon
saying "click me" on your desktop, and clicking on it will run it.

-Ray